Performance Evaluation of Permissioned Platforms

Ahmed Afif Monrat Olov Schelen´ Karl Andersson PhD Student Professor Associate Professor Lulea˚ University of Technology Lulea˚ University of Technology Lulea˚ University of Technology Skelleftea,˚ Sweden Skelleftea,˚ Sweden Skelleftea,˚ Sweden Email: [email protected] Email: [email protected] Email: [email protected]

Abstract—Blockchain is a technology for storing an immutable join the network to initiate and validate transactions [8]. Due history of transactions in a decentralized platform by using to a large number of nodes in a public network, a proof of cryptographic principles. Many industries have become inter- work consensus approach is applied to order transactions and ested in adopting blockchain within their IT systems. However, the accessibility, privacy, performance, and scalability aspects of create blocks. In a public blockchain, the the identity of the different blockchain-based platforms are still legitimate concerns address/account owner is typically unknown. when designing an enterprise solution. Permissioned blockchain In a permissioned blockchain, the identities of the owners frameworks facilitate a way to immutably store confidential are known and authenticated cryptographically [9]. This net- records. Numerous research studies have been carried out on work can have built in extensive access control mechanisms the opportunities, challenges, application areas, and performance analysis of different public and permissioned blockchain-based to limit the access and issue transactions in the blockchain platforms. However, the implication of blockchain in recent network. private enterprise solution requires detailed comparative analysis. Permissionless platforms are substantially concerning rea- This paper conducts a performance and scalability analysis garding performance, scalability and privacy due to their of popular private blockchain platforms, including (private deployment), Quorum, Corda, and Fabric. open access nature and resource expensive consensus process Each of these platforms is assessed by varying the workloads [10]. Conversely, the permissioned network is highly suitable (no. of transactions and nodes) and determining the performance for enterprise applications by ensuring the accessibility of evaluation metrics such as throughput and network latency. authenticated participants while avoiding a complex consensus Index Terms—permissioned blockchain; performance evalua- approach, which renders these platforms energy and resource tion, transaction, Ethereum, Hyperledger fabric, Corda, Quorum, Caliper efficient [11]. Therefore, it is not fair to compare public blockchain networks with private platforms while analyzing the performance issues. I.INTRODUCTION This paper focuses on the performance and scalability eval- Blockchain is a distributed technology (DLT) that uation of permissioned blockchain platforms. These following provides an immutable and trustable ledger of records. Since queries need to be answered: It was first introduced in 2008 [1], blockchain technology has surpassed applications. Blockchain has a) How does each permissioned blockchain platform react become an emerging and leading technology that promises to varying workloads regarding the number of transac- to revolutionize financial services [2], supply chains [3], tions and nodes that are associated with the evaluation? healthcare [4], energy [5] and public services [6]. Blockchain b) On which context does one platform facilitate better supports a , where an identical copy of the performance than the other platforms? ledger is replicated throughout a blockchain network. The To answer these questions and to identify performance technology typically allows transactions to be anonymous and bottlenecks, this paper aims to present a quantitative analy- secured among business partners, and automatically verifies sis to investigate the performance of different permissioned and records data using cryptographic algorithms without the blockchain based platforms by varying the network work- need for a central authority or intermediary. Several blockchain loads. For this research, we have considered platforms such frameworks that provide adaptable and flexible platforms and as Ethereum (private) [12], Corda [13], Quorum [14] and support various applications have become available. While Hyperledger Fabric [15]. The network workload refers to a several blockchain projects are being piloted, there are some varying number of transactions, transaction rates and transac- concerns about the technical challenges of a blockchain plat- tion types. Performance of the blockchain network that is being form in terms of its throughput, latency and its ability to evaluated include the throughput (in transactions per second, scale [7]. A blockchain network can be either permissionless tps), latency (in seconds) and scalability (i.e. the number of (public) or permissioned (private). In a permissionless network participants that the blockchain network can serve). The major or public network such as Bitcoin and Ethereum, anyone can contributions for this paper are listed as follows: a) An empirical study of recent consensus protocols for III.CONSENSUS PROCESSIN DIFFERENT PERMISSIONED permissioned blockchain platforms. BLOCKCHAIN PLATFORMS b) A quantitative performance analysis of different per- In a blockchain network, while processing a block, the missioned blockchain platforms by varying the network nodes are required to perform certain activities, such as workloads, which reveals the limitations and bottlenecks participating in the authentication and verification of the of these systems. transactions, block mining activities, communication over c) Implementation of a proof of concept using a cloud the network, and collaborative construction of trust within computing service to facilitate the ideal environment the blockchain system without the interference of a central for deploying and evaluating these platforms. authority. There is always the risk that individual nodes may behave maliciously or act against the principle goal or that This paper is organized as follows: Section II provides the network communication crashes. To facilitate continuous an overview of the related works. Section III introduces the service that ensures the availability, confidentiality, integrity, consensus protocols that are employed in the permissioned and accessibility, a secure mechanism is needed to make all blockchain platforms. In section IV, the deployment of the per- the participant nodes reach a global agreement about which missioned blockchain platforms in cloud computing services information should be appended to the blockchain [27]. This is presented. Section V presents the results and discussion process is known as a consensus protocol, which stimulates on the the performance and scalability evaluation. Section VI the trust of all nodes in the blockchain system. concludes the paper. This section presents a brief discussion on some of the widely utilized consensus approaches in different permissioned blockchain platforms, such as PBFT, RAFT, Apache Kafka, II.RELATED WORKS proof of authority (PoA) and QuorumChain. A. PBFT Dinh et al. proposed a Blockbench framework for bench- Practical Byzantine Fault Tolerance (PBFT) is an improved marking the performance of private blockchain platforms [16]. version of the Byzantine fault tolerance (BFT) consensus This research conducts a performance comparison among algorithm, where members are partially trusted and the system private blockchain platforms such as Parity, Ethereum and can resist the class of failures derived from the Byzantine Fabric (Version 0.6). To predict the latency of blockchain Generals’ Problem [28]. This consensus approach is mostly based systems, Yasaweerasinghelage et al. proposed a sim- seen in the Hyperledger Fabric platform. PBFT facilitates the ulation framework and performance modeling [17]. Sukhwani certainty of reaching a consensus even when the network et al. presents a performance modeling framework for a consists of malicious nodes. However, the number of malicious permissioned blockchain network that incorporates a PBFT nodes in the network should not exceed more than one-third consensus protocol [18]. Kocsis et al. proposed a performance of the total number of nodes, which can be considered as a evaluation model for blockchain technology, which was uti- significant constraint. The network becomes more secure as lized to evaluate Hyperledger fabric v0.6 [19]. A comparison the number of nodes increases. To complete a transaction, the between and Byzantine fault tolerance based majority or at least 51% of the nodes in the network have to regarding scalability and performance is presented approve the transaction [29]. It is important to observe that by Vuckolic et al. [20]. A performance evaluation for two pri- the protocol does not require a 100% consensus ratio because vate blockchain implementations; Ethereum and Hyperledger a valid transaction can be rejected if one malicious node does fabric, by varying the number of transactions was presented not approve the transaction. Some nodes in a permissioned by Suporn et al [21]. Other works in this field are focused network might reject the transaction with malicious intent. The on evaluating the security, performance and scalability aspects PBFT consensus approach can address this issue. However, the of both public and private blockchains [22], [23], [24], [25], message count increases exponentially while adding nodes or [26]. Based on this literature survey, table I presents a com- replicas in a PBFT network. parison among permissioned blockchain platforms. The design challenges in public platforms are quite different from those B. RAFT involved in building permissioned platforms, and therefore, a Permissioned Blockchain platforms such as Quorum and direct comparison of performance between the two types of Hyperledger Fabric use the RAFT consensus algorithm. platforms is not fair. To the best of our knowledge, we did This consensus approach ensures that all the nodes in a not identify any papers that conduct a thorough performance cluster agree upon the same series of state transition by and scalability evaluation among permissioned blockchain offering a generic way to distribute a state machine across a platforms, especially among Ethereum, Corda, Quorum, and cluster of computing systems [30]. Nodes in RAFT can have Hyperledger. Therefore, this research aims to determine the separate identities, such as candidate, follower or leader. The discrepancies regarding performance, such as throughput and nodes nominate the leader via a process known as election. latency, among these permissioned blockchain platforms. The leader is responsible for sending all messages to the TABLE I COMPARISONAMONGPERMISSIONED BLOCKCHAIN PLATFORMS

Blockchain Platforms Ethereum Hyperledger Fabric Quorum Corda Type Public Enterprise Enterprise Enterprise Purpose Cross-Industry Cross-Industry Cross-Industry Financial Services Purpose Business to Client (B2C) Business to Business Financial Service Industry Financial Service Industry (B2B) Program- GoLang, NodeJs Solidity Kotlin, Java ming Language Currency Ether Can be built using chain- Ether No native Cryptocurrency codes (Corda coin) Governance DAO Linux Foundation Ethereum Foundation R3 Consensus Algorithm PoW PBFT RAFT Pluggable Consensus Throughput A few 100s more than 200 tps 200 tps 200 tps participating nodes in the network. Initially, when the leader verifying the blocks and transactions. receives a message, it propagates the message to other nodes. These nodes conduct the writing and verification process. The E. QuorumChain leader only commits the message when all the nodes reach to an agreement about writing the message and sending a QuorumChain uses a smart contract to validate blocks [35]. response to the leader. At this point, the follower nodes also The model has a set of “voter” and “block-maker” nodes, commit the message, and a consensus is reached. RAFT is whose identities are known to the network. This protocol tolerant for handling network partition failure. implies the standard peer to peer gossip layer of Ethereum to form the blocks. The logic is formulated as a smart contract that is deployed with the genesis block. All the messages C. Apache Kafka are digitally signed by the nodes. The block-maker nodes Apache Kafka is not a traditional consensus protocol; it propose the block to be added in the network, while the voter is a publish-subscribe solution that supports topics, wherein nodes are responsible for the approval and validation process. published messages are serialized in the same order for all By default, there is one block-maker node in this network. subscribers. Apache Kafka is crash fault tolerant (CFT), which prevents the system from failing when the nodes crash or go IV. DEPLOYMENTOF BLOCKCHAIN PLATFORMS IN offline [31]. However, it is not BFT, which prevents the system CLOUD COMPUTING SERVICE from reaching an agreement in the case of malicious or faulty nodes. This protocol is mostly employed in a Hyperledger This section describes the deployment of permissioned Fabric ordering service. Apache Kafka is a permissioned blockchain in cloud computing services. The perks of voting-based distributed streaming platform that is aimed at integrating blockchain are similar to other distributed systems, high throughput and low latency [32]. Apache Kafka consists such as booting, accessing, and scaling a system with ease of two types of nodes: broker nodes and consistency nodes. compared to an on-premises network. For developing a proof The network messaging is processed by a set of redundant bro- of concept, we chose the Microsoft Azure Platform. Azure kers. To address the network issues and crashes, a Zookeeper provides a different service model, such as Infrastructure instance is employed in the consistency nodes that coordinate as a service (IaaS) and platform as a service (PAAS), for the brokers. The ordering process is carried out by the leader provisioning a fully configured blockchain network topology. and only in-sync replicas can be voted as leader. Cloud services are used to develop the proof of concept to mitigate the challenges in performing a complex performance D. PoA evaluation in a local machine. Moreover, establishing a system Proof of authority (PoA) refers to a reputation-based configuration for blockchain-based solutions is complicated. consensus algorithm that introduces a practical and efficient solution for the private implementation of blockchain networks 1) PoA Ethereum Deployment: Azure Blockchain Service [33]. This consensus can be utilized in the Ethereum network provides an Ethereum PoA consortium template, which for private deployment purposes. In PoA, the block validators facilitates deploying, configuring, and provisioning a network. are staking their reputation or identity instead of coins This template can be utilized by any consortium member which makes this algorithm different from nodes to provision a block network. There is a set of (PoS). PoS is not always suitable for certain businesses activities that need to be performed to deploy a PoA network, and corporations due to the decentralized nature of most which includes VMs for running PoA validators; using blockchain networks [34]. Conversely, PoA systems may Azure load balancer for distributing RPC, peering, and represent a better solution for private blockchains because it governance DApp requests; and managing Azure Monitor for can provide higher throughput. The preapproved participants aggregating logs and performance statistics. First, we need act as moderators of this system and are responsible for an Azure subscription to access the Azure portal. Second, we facilities, such as CorDapps, health monitoring and logging information, customizing alerts and actions, and creates custom visualization of health monitoring data.

4) Hyperledger Fabric Deployment: Hyperledger Fabric network can be deployed and configured on Azure using the Azure Kubernetes Service (AKS) template. We deployed an ordering service and organizations with peers to build the Hyperledger Fabric network using the AKS. This template consists of components such as orderer nodes, peer nodes, a certificate authority (CA), and a world state database for the peer nodes. The Orderer node is responsible for carrying out transaction ordering in the ledger. Peer nodes host smart con- tracts and ledgers. Fabric CA allows us to manage certificates and identities. For storing chaincode data as simple key/value pairs and supporting composite key queries, LevelDB and CouchDB are applied as a default state database that is embedded in the peer nodes.

Fig. 1. Ethereum PoA deployment in Microsoft Azure platform V. RESULTS &DISCUSSION This segment identifies the performance matrices for eval- uating permissioned blockchain platforms. In this section, the deploy the Ethereum PoA consortium template by specifying performance and scalability of Ethereum, Quorum, Corda and some parameters, such as resource groups, subscription, Hyperledger Fabric are demonstrated based on the network authentication type, VM size, network size, etc. Fig. 1 shows latency, and throughput. An experiment was carried out by the deployed Ethereum PoA overview, which includes blocks, assessing the performance of both a single-peer network transactions, pending transactions, etc. and a multipeer network. Further, a smart contract and the experimental setup to evaluate the platforms are discussed. 2) Quorum Deployment: In Azure, the Quorum consortium can be deployed by providing some parameters. However, it A. Performance Metrics is mandatory to understand the network architecture of the 1) Latency: Latency is a network-wide view of the amount Quorum blockchain platform. The implementation of Quorum of time taken for a transaction’s effect to be usable across the consists of QuorumChain, constellation, and peer security. network. Quorum platform uses the constellation as a tool for peer to peer encrypted message exchange. Peer security refers to 2) Throughput: Transaction throughput is the rate at which the node permissions using a smart contract. Similar to the valid transactions are committed to a blockchain in a defined deployment of a previous permissioned blockchain network, time period. we need to initiate the VM using an Azure subscription. Azure Marketplace has a deployment template known as the ‘Quorum Consortium Network’. This template will generate B. Workloads & Smart Contract the VMs after specifying the standard parameters such as We have deployed a simple marketplace smart contract subscription, resource group, and basic VMs properties. or chaincode to evaluate the performance of blockchain The infrastructure deployed in Azure will deploy all virtual platforms. A smart contract is a piece of code that is intended machines a single virtual network and a single subnet inside to digitally facilitate, verify, or enforce the negotiation or this network. performance of a contract while triggering a transaction in the blockchain network [36]. This application expressed a 3) Corda Deployment: Azure Blockchain service facilitates workflow for simple transactions between an owner and a the ability to provision Corda nodes in a private Corda buyer in a marketplace. There are two roles in this application: network. It simplifies the process by providing easy owner and buyer. The owner is an individual who wants to configuration and deployment of the Corda node within sell on the marketplace, whereas the buyer wants to buy the Azure portal or programmatically via REST APIs, CLI, the products. The network consists of three sample states: or PowerShell. In addition to provisioning and deploying ItemAvailable, OfferPlaced, and Accepted. ItemAvailable Corda nodes, Azure Blockchain Service provides managed indicates that the owner has made his product available in APIs to help you manage your Corda nodes and Corda the marketplace to sell. OfferPlaced refers to the offer made Distributed Applications (CorDapps). By leveraging the by the buyer to purchase the item from the marketplace. Azure monitor within Azure Blockchain Service provides Accepted state defines that the owner has accepted the buyer’s Fig. 2. Marketplace Application’s State Transition bidding for the product.

As shown in Fig. 2, the application’s workflow starts when the ItemAvailable state is initiated by the owner. In this state, the owner specifies the details and price of a product and makes it available for sale. Once the item is listed in the marketplace, a buyer can make a bid for this item by specifying the amount that he wants to pay. The state Fig. 3. Latency comparison between PoW-Ethereum and PoA-Ethereum is changed from ItemAvailable to OfferPlaced due to this action. If the owner accepts the bid then the owner calls the function to accept the offer, the workflow reaches a successful conclusion and the state is changed to Accepted. Conversely, if the owner is not satisfied with the offer from the buyer, then the owner can call a function to reject the offer. At this stage, the state is changed to ItemAvailable again, which indicates that the item is still up for sale. The transitions between these states can continue until the buyer and seller reach to an agreement. This smart contract is deployed in the permissioned blockchain platforms before evaluating the performance of the platforms.

C. Evaluation Environment Configuration

All these permissioned platforms are deployed and run Fig. 4. Throughput comparison between PoW-Ethereum and PoA-Ethereum on Microsoft Azure VMs. For this experiment, we utilized Standard D4sv3 instances with 4 vCPUs at 3.7 GHz and 16 GB RAM. All the nodes have the Ubuntu 18.04 LTS operating transaction latencies by sending controlled workloads to the system. To integrate the workloads (concurrent transactions Quorum network. Caliper’s measurement framework operates and nodes) in the network and evaluate the performance and on the client machines and sends transactions to peers in the scalability of the private blockchain platforms, each network Quorum network. Next, we chose BLOCKBENCH, which is was configured with a maximum cluster of 24 peer nodes. an evaluation framework for analyzing private blockchains The maximum number of concurrent transactions that are to evaluate the Ethereum platform. This tool is capable of deployed as workloads is 10000. measuring metrics such as latency, throughput, fault-tolerance, and scalability. A simple set of APIs can be used to integrate We used a blockchain benchmark tool named Hyperledger the blockchain platforms and workloads. The performance Caliper. This tool allows users to measure the performance evaluation of the Corda platform has been carried away by of a blockchain network with a set of predefined use cases. installing the Corda Enterprise performance test suite for Hyperledger project has now officially incubated Caliper. The deploying a single node or a small set of nodes including performance of a blockchain network can be measured by a notary. This test suite uses Apache JMeter to start flows on using this tool with a set of predefined use cases. The results nodes via RPC calls and capture the latency and throughput. generated by Caliper facilitates some insights on the perfor- mance and scalability to the Hyperledger projects, especially D. Performance & Scalability Analysis in supporting the choice of a blockchain implementation that is suitable for a user’s specific needs. For analyzing the perfor- This section analyzed the performance and scalability as- mance of the Quorum blockchain network, we have employed pects of the permissioned blockchain platforms considering the Caliper benchmarking tool integrated with a Quorum metrics such as latency and throughput. plugin. This plugin helps Caliper to record the throughput and Enterprise 4.3 for two reasons. First, In Corda Enterprise 4.5, flows that execute in parallel have significantly lower latency. This reduced latency means that nodes are able to complete more flows in the same amount of time, which achieves higher throughput. Second, the peer-to-peer messages between nodes can be compressed, which can lead to more efficient use of network bandwidth.

Fig. 6 shows that Corda Enterprise 4.3 shows exponential growth in the latency as the number of nodes that participate in the transaction are increased. Corda Enterprise 4.3 processes a transaction resolution in bulk, instead of one state at a Fig. 5. Throughput Comparison between Corda Enterprise 4.3 and 4.5 time. Compared to Corda Enterprise 4.3, Corda Enterprise 4.4 shows a large decline in latency because the execution of the flows is sequential across the nodes; however, the cost per node is significantly smaller. Finally, Corda Enterprise 4.5 demonstrates the lowest latency flow in comparison with other versions due to the parallelized flow. Therefore, Corda Enterprise 4.5 can scale best with the growth in network size (nodes). The presence of additional participants has minimal impact on its latency.

Fig. 7 depicts the latency and throughput measurement of the Quorum platform with the growth in network size. We observe that the latency grows linearly with an increase in the number of peer nodes in the network. The latency reached its peak with 8 nodes and then experiences an exceptional depletion when the network grows further. This finding could Fig. 6. Latency Comparison among Corda Enterprise 4.3,4.4 and 4.5 be due to the overhead communications and experimental setup of the Quorum platform, which cannot handle more than 10 nodes in the network. On the other hand, the throughput From Fig. 3 and Fig. 4 we can easily distinguish the is higher and experiences constant growth of the network up performance gap between PoA-based Ethereum deployment to 4 nodes; then it shows a steep decline. and PoW-based Ethereum deployment. The PoA-Ethereum outperforms PoW-Ethereum in terms of the network latency Fig. 8 presents the scalability evaluation of the Hyperledger and throughput, due to the deployed consensus protocol. Fabric platform by varying the number of nodes up to 20. PoA is a much simpler and efficient protocol compare to It can be observed that the scalability analysis is performed PoW. The throughput in PoW-Ethereum is significantly using the same metrics such as latency and throughput lower than PoA-Ethereum due to the tradeoff between the while using two different sets of transactions (1000Tx and decentralization and transaction throughput. PoW-Ethereum 10000Tx). The results showed that the network can scale prefers decentralization by not trusting a small set of peers to up to 16 nodes due to the overhead communication among orchestrate the block production and achieve a consensus by nodes in the consensus protocol. Moreover, the platform allowing any node to participate in the network. Conversely, cannot operate 10000 transactions when the number of nodes PoA-Ethereum acts similar to a centralized consortium that in the network exceeds 4 with the deployed experiment processes transactions faster by relying on the fewer and setup. Therefore, it can be seen that the performance of this known participants in the network. platform deteriorates if the number of peer nodes in the network increases. Another interesting observation is that PoW-Ethereum’s throughput remain steady, because PoW is not dependent on Fig. 9 and Fig. 10 demonstrates the comparison of latency the number of participating nodes. However, our results show and throughput, respectively, among Ethereum, Quorum, that the performance initially rises but starts to decrease once Corda, and Hyperledger fabric platforms. We can observe a peak is reached, when nodes are added to the PoA-Ethereum that Hyperledger Fabric out-performs Ethereum and Quorum setting. with a large margin but performed slightly better than Corda. Hyperledger Fabric facilitates a short latency period while Fig. 5 depicts that Corda Enterprise 4.5 can achieve a processing transactions compared to other permissioned significantly higher throughput when compared to Corda platforms. Therefore, this platform is capable of providing Fig. 7. Latency and Throughput measurement of Quorum (Nodes)

Fig. 8. Latency and Throughput measurement of Hyperledger Fabric for 1000 and 10000 transactions

Fig. 10. Comparison of throughput among Ethereum, Quorum, Corda and Hyperledger Fabric platforms Fig. 9. Comparison of Latency among Ethereum, Quorum, Corda and Hyperledger Fabric platforms VI.CONCLUSION &FUTURE SCOPE This research presents a performance and scalability analy- sis of permissioned blockchain platforms, including PoA based better throughput as well. Our experimental observations Ethereum, Quorum, Corda, and Hyperledger. These platforms reveal that Hyperledger Fabric is performing better than other are assessed by varying the deployed concurrent transactions private platforms due to its simple and efficient modular as workloads and increasing the network size (nodes) to consensus approach. determine the scalability. Overall, the performance analysis results across all evaluation metrics, such as throughput and latency, illustrate that Hyperledger Fabric performs better than [15] C. Cachin et al., “Architecture of the hyperledger blockchain fabric,” in other permissioned platforms. These private blockchains are Workshop on distributed and consensus ledgers, vol. 310, no. 4, 2016. deployed in the Microsoft Azure cloud computing platform to [16] T. T. A. Dinh, J. Wang, G. Chen, R. Liu, B. C. Ooi, and K.-L. facilitate the computational resources that are required to per- Tan, “Blockbench: A framework for analyzing private blockchains,” in form the evaluation. The approach of the experimental setup Proceedings of the 2017 ACM International Conference on Management of Data, 2017, pp. 1085–1100. in cloud service is a major strength of this research regarding [17] R. Yasaweerasinghelage, M. Staples, and I. Weber, “Predicting latency of performance benchmarking, instead of fragile deployments blockchain-based systems using architectural modelling and simulation,” on local machines or speculative simulations. However, this in 2017 IEEE International Conference on Software Architecture (ICSA). IEEE, 2017, pp. 253–256. experiment uses different benchmarking tools, such as Caliper, [18] K. Zheng, Y. Liu, C. , Y. Duan, and X. Huang, “Model checking pbft Blockbench and Corda enterprise test suite, to evaluate each consensus mechanism in healthcare blockchain network,” in 2018 9th of these platforms, which can be considered as a drawback. A International Conference on Information Technology in Medicine and Education (ITME). IEEE, 2018, pp. 877–881. single framework and test suite that supports these platforms [19] T. Nakaike, Q. Zhang, Y. Ueda, T. Inagaki, and M. Ohara, “Hyperledger could render the analysis more efficient and fair. In addition, fabric performance characterization and optimization using goleveldb the security concerns and energy consumption are not con- benchmark,” in 2020 IEEE International Conference on Blockchain and Cryptocurrency (ICBC). IEEE, 2020, pp. 1–9. sidered evaluation metrics. Addressing these limitations and [20] Q. Nasir, I. A. Qasse, M. Abu Talib, and A. B. Nassif, “Performance optimizing the consensus approaches of these permissioned analysis of hyperledger fabric platforms,” Security and Communication blockchain platforms can be considered in future work. Networks, vol. 2018, 2018. [21] S. Pongnumkul, C. Siripanpornchana, and S. Thajchayapong, “Perfor- mance analysis of private blockchain platforms in varying workloads,” in CKNOWLEDGMENT A 2017 26th International Conference on Computer Communication and This study was supported by the Swedish Energy Agency Networks (ICCCN). IEEE, 2017, pp. 1–6. [22] H. Sukhwani, N. Wang, K. S. Trivedi, and A. Rindos, “Performance under grant 43090-2, Cloudberry Datacenters. modeling of hyperledger fabric (permissioned blockchain network),” in 2018 IEEE 17th International Symposium on Network Computing and Applications (NCA). IEEE, 2018, pp. 1–8. EFERENCES R [23] Z. Ma, J. Fan, Y. Zhang, and L. Liu, “Performance analysis of blockchain [1] S. Nakamoto et al., “Bitcoin: A peer-to-peer electronic cash system”,” consensus system with interference factors and sleep stage,” IEEE 2008. [Online]. Available: http://bitcoin.org/bitcoin.pdf Access, vol. 8, pp. 119 010–119 019, 2020. [2] K. Fanning and D. P. Centers, “Blockchain and its coming impact on [24] K. S. Hald and A. Kinra, “How the blockchain enables and constrains financial services,” Journal of Corporate Accounting & Finance, vol. 27, supply chain performance,” International Journal of Physical Distribu- no. 5, pp. 53–57, 2016. tion & Logistics Management, 2019. [3] F. Longo, L. Nicoletti, A. Padovano, G. d’Atri, and M. Forte, [25] M. Kuzlu, M. Pipattanasomporn, L. Gurses, and S. Rahman, “Perfor- “Blockchain-enabled supply chain: An experimental study,” Computers mance analysis of a hyperledger fabric blockchain framework: through- & Industrial Engineering, vol. 136, pp. 57–69, 2019. put, latency and scalability,” in 2019 IEEE international conference on [4] L. Ismail, H. Materwala, and S. Zeadally, “Lightweight blockchain for blockchain (Blockchain). IEEE, 2019, pp. 536–540. healthcare,” IEEE Access, vol. 7, pp. 149 935–149 951, 2019. [26] H. Kalodner, M. Moser,¨ K. Lee, S. Goldfeder, M. Plattner, A. Chator, [5] N. Wang, X. Zhou, X. Lu, Z. Guan, L. Wu, X. Du, and M. Guizani, and A. Narayanan, “Blocksci: Design and applications of a blockchain “When energy trading meets blockchain in electrical power system: The analysis platform,” in 29th {USENIX} Security Symposium ({USENIX} state of the art,” Applied Sciences, vol. 9, no. 8, p. 1561, 2019. Security 20), 2020, pp. 2721–2738. [6] Z. Engin and P. Treleaven, “Algorithmic government: Automating public [27] Y. Lu, “The blockchain: State-of-the-art and research challenges,” Jour- services and supporting civil servants in using data science technolo- nal of Industrial Information Integration, vol. 15, pp. 80–90, 2019. gies,” The Computer Journal, vol. 62, no. 3, pp. 448–460, 2019. [28] M. Correia, “From byzantine consensus to blockchain consensus,” [7] A. A. Monrat, O. Schelen,´ and K. Andersson, “A survey of blockchain Essentials of Blockchain Technology (2019), vol. 41, 2019. from the perspectives of applications, challenges, and opportunities,” [29] A. Banafa, “Iot and blockchain convergence: benefits and challenges,” IEEE Access, vol. 7, pp. 117 134–117 151, 2019. IEEE Internet of Things, 2017. [8] X. Xu, I. Weber, M. Staples, L. Zhu, J. Bosch, L. Bass, C. Pautasso, and [30] D. Huang, X. Ma, and S. Zhang, “Performance analysis of the raft P. Rimba, “A taxonomy of blockchain-based systems for architecture de- consensus algorithm for private blockchains,” IEEE Transactions on sign,” in 2017 IEEE International Conference on Software Architecture Systems, Man, and Cybernetics: Systems, vol. 50, no. 1, pp. 172–181, (ICSA). IEEE, 2017, pp. 243–252. 2019. [9] S. Y. Lim, P. T. Fotsing, A. Almasri, O. Musa, M. L. M. Kiah, T. F. [31] B. Podgorelec, V. Kersiˇ c,ˇ and M. Turkanovic,´ “Analysis of fault toler- Ang, and R. Ismail, “Blockchain technology the identity management ance in permissioned blockchain networks,” in 2019 XXVII International and authentication service disruptor: a survey,” International Journal on Conference on Information, Communication and Automation Technolo- Advanced Science, Engineering and Information Technology, vol. 8, no. gies (ICAT). IEEE, 2019, pp. 1–6. 4-2, pp. 1735–1745, 2018. [32] P. Le Noac’H, A. Costan, and L. Bouge,´ “A performance evaluation of [10] K. Salah, M. H. U. Rehman, N. Nizamuddin, and A. Al-Fuqaha, apache kafka in support of big data streaming applications,” in 2017 “Blockchain for ai: Review and open research challenges,” IEEE Access, IEEE International Conference on Big Data (Big Data). IEEE, 2017, vol. 7, pp. 10 127–10 149, 2019. pp. 4803–4806. [11] N. El Ioini and C. Pahl, “A review of distributed ledger technologies,” [33] A. H. Lone and R. N. Mir, “Reputation driven dynamic access control in OTM Confederated International Conferences” On the Move to framework for iot atop poa ethereum blockchain.” IACR Cryptol. ePrint Meaningful Internet Systems”. Springer, 2018, pp. 277–288. Arch., vol. 2020, p. 566, 2020. [12] A. E. Gencer, S. Basu, I. Eyal, R. Van Renesse, and E. G. Sirer, [34] J. Y. Lee, “A decentralized token economy: How blockchain and “Decentralization in bitcoin and ethereum networks,” in International cryptocurrency can revolutionize business,” Business Horizons, vol. 62, Conference on Financial Cryptography and Data Security. Springer, no. 6, pp. 773–784, 2019. 2018, pp. 439–457. [35] F. Gao, F. Jiang, Y. Zhang, and R. Doss, “Quorum chain-based malware [13] D. Mohanty, “Corda architecture,” in R3 Corda for Architects and detection in android smart devices,” in International Conference on Developers. Springer, 2019, pp. 49–60. Future Network Systems and Security. Springer, 2019, pp. 212–224. [14] T. Espel, L. Katz, and G. Robin, “Proposal for protocol on a quorum [36] S. Wang, Y. Yuan, X. Wang, J. Li, R. Qin, and F.-Y. Wang, “An overview blockchain with zero knowledge.” IACR Cryptol. ePrint Arch., vol. 2017, of smart contract: architecture, applications, and future trends,” in 2018 p. 1093, 2017. IEEE Intelligent Vehicles Symposium (IV). IEEE, 2018, pp. 108–113.