PetroBlock: A Blockchain-Based Payment Mechanism for Fueling Smart Vehicles

Abstract

Current developments in information technology and increased inclination towards smart cities have led to the initiation of a plethora of features by technology-oriented companies (i.e., car manufacturers) to improve users’ privacy and comfort. The invention of smart vehicle technology paved the way for the excessive use of machine-to-machine technologies. Moreover, third-party sharing of financial services are also introduced that support machine-to-machine (M2M) communication. These monetary systems’ prime focus is on improving reliability and security; however, they overlook aspects like behaviors and users’ need. For instance, people often hand over their bank cards or share their credentials with their colleagues to withdraw money on their behalf. Such behaviors may originate issues about privacy and security that can have severe losses for the card owner. This paper presents a novel blockchain-based strategy for payment of fueling of smart cars without any human interaction while maintaining transparency, privacy, and trust. The proposed system is capable of data sharing among the users of the system while securing sensitive information. Moreover, we also provide a blockchain-based secure privacy-preserving strategy for payment of fueling among the fuel seller and buyer without human intervention. Furthermore, we have also analytically evaluated several experiments to determine the proposed blockchain platform’s usability and efficiency. Lastly, we harness Hyperledger Caliper to assess the proposed system’s performance in terms of transaction latency, transactions per second, and resource consumption.

1. Introduction

The emergence of Internet of Things (IoT) technologies plays a vital role in various walks of human life, including business, agriculture, healthcare, transport, etc. According to Cisco and Ericsson, the quantity of IoT devices in daily usage will exceed over 100 billion by 2020 [1]. IoT devices, i.e., smart mirrors, smart cameras, smart cars, smartphones, etc., connect a user with a diverse range of services like traveling, manufacturing, transactions, etc., by harnessing the Internet. Most of these IoT devices depend upon machine-to-machine (M2M) communication, which involves communication without humans’ intervention. The M2M communication-based systems are capable of automating the process transaction through online payment systems [2]. Although M2M communication transactions are broadly being harnessed across the globe, the context data in M2M communication have a severe concern regarding security and privacy. The contemporary M2M-based applications face three significant challenges: (i) transparency, (ii) interoperability, and (iii) trust [3]. Transparency is one of the most significant issues faced by IoT and M2M-based applications. The current IoT and M2M devices are highly insecure in nature; therefore, communication among them must be secured by employing different encryption techniques. Moreover, data ownership is also non-persistent in these devices. Encrypting IoT and M2M infrastructure involves huge complexity. Interconnection among peripherals enhances productivity in industrial settings as well as residential area. However, when the quantity of devices increases and network connections expand due to increased population, the issue of interoperability arises. The third challenge involves the trust of users. Figure 1 illustrates an example of M2M communication wherein a smart vehicle uses limited-range wireless communication (e.g., Bluetooth and NFC) to make payment for refueling while the user of the smart car trusts vendor by providing credit card information. The smart car and gas station are equipped with IoT applications that hold the digital wallet of a user.

The M2M and IoT applications that exchange physical or digital assets of users should be reliable and provide risk-free interfaces during transactions. However, the current IoT applications do not hold a consistent structure for the security, access control, and privacy-related models [4]. This raises serious concerns related to the safety and reliability of transaction processing. Recently, there has been a boom of the latest Information technology Blockchain [5]. The concept of blockchain is deemed as a decentralization ledger shared among all connected networks. Since it is not feasible to mathematically update the ledger, cryptographic-based methods are employed for the said purpose. The data structure of a blockchain comprises immutable, ordered, and timestamped data blocks. Each block in a design holds a connection with the preceding block, which forms a strict order. In a blockchain, the first block is known as the genesis block used to create the blockchain blocks, also known as block zero. These blocks consist of multiple ordered transactions. Such data structure allows provenance wherein a transaction has a single origin. All users involved in the blockchain network authenticate and approve the transaction. It is a decentralized technology wherein all records are maintained at different locations. This decentralized behavior enables blockchain to govern under multiple entities, indicating that governments or other authorities do not have any access to that. Therefore, the data in the blockchain system could not be altered.

Blockchain has significant properties that directly address the challenges of Intelligent Transportation System (ITS). Therefore, the companies dealing with financial services emphasize on using blockchain because it ensures highly secured transactions of assets [6]. Furthermore, it provides transparency like public-audibility, an append-only ledger of transactions involved in the chain. The recent emerging of blockchain technology supports the shifting of the traditional payment system at a gasoline pump into a secure automated system [7]. Smart contracts and Hyperledger Fabric can be employed for allowing a software platform to run without a trusted third party. This behavior leads to opening up opportunities for harnessing product-centric enterprise systems. In this study, a secure payment method is implemented to refuel smart vehicles at smart pumps. The designed model leverages the blockchain platform (i.e., Hyperledger Fabric [8,9]) to secure the transfer of payment and share information among different gasoline pumps. Firstly, we propose a novel blockchain payment method to fuel smart vehicles in which a user can share sensitive information like credit card credentials or others in a secured, authentic chain of connected networks of the associated franchises of gasoline pumps. This blockchain model is extended towards a web-driven system by designing web front-end technologies like HTML5 and JavaScript for enhancing resource management in a network. Furthermore, we also configure composer-rest-server to expose REST API to visualize services related to the designed system. Afterward, smart contracts’ functionality is embedded to enable data uniformity of card and bank information and other users’ assets and other participants involved in the network. Afterward, an Access Control List (ACL) is defined, which provides access to only valid and authentic users. To enhance the model’s efficiency and performance, we employ DBCouch [10] to manage a large number of records and evade form data redundancy problems within the blockchain File System. The performance of the proposed system is evaluated using Hyperledger Caliper [11,12], a benchmarking tool for blockchain-based system [11,13].

More precisely, the contributions of this paper are as following:

• We present PetroBlock: A secure payment mechanism for refueling smart vehicles without human interaction, providing transparency, trust, and privacy.
• The proposed model can share data among the system’s users while securing sensitive information.
• We evaluate the designed system using Hyperledger Caliper in terms of transaction latency (average, percentile, minimum and maximum), transaction throughput, resource utilization (e.g., CPU, memory, I.O. ).

The rest of the paper is structured as follows: Section 2 explains the state-of-the-art related work on payment mechanisms for fueling smart vehicles. Section 3 presents the designed methodology, smart contract modeling, implementation, and storage design. Section 4 gives the details of the system results, and Section 5 concludes the paper.

2. Related Work

This section encompasses preliminary studies related to the secure payment mechanism and refueling of the smart vehicle by harnessing smart contract and blockchain technologies. Many studies have been presented to interact blockchain with machines [14,15,16,17,18,19,20,21,22,23].

In [24], authors proposed an automated scheme to charge the electric vehicle by taking dynamic tariff decisions in a privacy-preserved manner by exploiting distance and price information. The presented system is based on a blockchain platform where electric vehicles send a signal with a charging station’s demand, similar to an auction bid. The owner of the electric vehicle opts for a specific charging station using the received supply-side offers. The proposed system is comprised of three parts: (i) the provided system finds the optimal charging station based on public bidding as a query response; (ii) the geographical position of the person is not revealed during protocol execution; (iii) the Distributed Ledger Technology (DLT) of blockchain for immutable storing of data related to the bidding of an electric vehicle.

The authors in [25] developed a model for an automatic fueling system for automobiles. The presented model comprises a fuel dispenser, which is movable, including a nozzle connected with the vehicle’s fuel inlet. The automatic fuel dispenses movement through a programmable unit helps it attach nozzle with a fuel inlet. The sensor implant in a car indicates the fuel dispenser’s direction to the fuel inlet through signals.

Smart contract to enable communication among machines is introduced in [3,26]. The authors presented the AGasP, an IoT application for machine-to-machine gasoline payment by using a smart contract. The proposed system uses a smart contract for the payment transaction. The developed method is based on Ethereum, and allows the user to audit all interactions between the design and the blockchain platform as long as the network of blockchain exists. The third parties that are part of the payment systems are removed via AGasP, and transaction charges are waived off up to 79% in comparison to the conventional method.

In [27], authors introduced a blockchain-based autonomous system that selects the most suitable charging stations for electric vehicle. The design system provides automated secure machine-to-machine payment, auction, and bidding. The system is developed on a Raspberry Pi and raspbian operating system. The proposed method is divided into three actors: A charging station, a vehicle, and a driver. The driver’s responsibility is to launch the selection procedure and confirm the bid suggested by the car. The car has two entities, the infotainment system provided by the electric vehicle and the blockchain-based smart contract contract [27]. A mobile application based on Ethereum was developed to provide the appropriate charging bid with automated payment.

In [28], authors presented the case study of an automatic payment mechanism based on the smart contract. When entering his/her car, the user’s smartphone automatically synchronizes with the AutoPay service. The autonomous payment service provides trust and security through smart contracts implemented as an adapter on its blockchain interface. The AutoPay service detects current fuel status and finds the route passed by a petrol station if fuel status is low. AutoPay automatically pays the fuel bill after refueling through smart contract features. AutoPay also pays for user’s car parking automatically through a smart contract when he/she goes to work.

In [29], ChargeItUp case study is presented to analyze the refueling scenario for an autonomous vehicle. The proposed system is an Ethereum-based system that sends transactions through smart contracts, mainly machine-to-machine (M2M). The proposed electric car charging company architecture consists of three parts: the client (the car user), the server (the charging station), and the blockchain smart contract. Firstly, the user went to the charging station to charge his car. The charging station and user agree on the price per unit of charging and other aspects to open the channel. The user sends an open channel notification to a charging station verified by the station, and they start the charging for the time specified by the user. In the end, the car user pays for the charging by sending the final transaction to the station.

In [30], a novel decentralized approach of electric vehicle charging and discharging is presented using a blockchain-enabled smart grid. Adaptive Blockchain-based Electric Vehicle Participation (AdBEV) scheme is proposed to reduce the power fluctuation level. Iceberg order algorithm is used to implement the beast order mechanism for matching the system designed for smart grid electricity charging and discharging. The ethereum-based platform can achieve a low consumption cost as compared to other ethereum-based E.V. systems.

Kim et al. in [31] proposed a blockchain-based mobile charger billing system. The design system is used to send online transactions securely in a peer-to-peer distributed network. The mobile charger may be grouped by utilizing the groupID. Moreover, using blockchain technology reduces the size of the data block. As explained earlier, the blockchain platform is permissionless or not open-source; therefore, a general user cannot modify it.

Nevertheless, none of these models have addressed the payment mechanism for refueling employing Hyperledger Fabric platforms. There is no functional payment mechanism model for refueling smart cars using Hyperledger technology to the best of our knowledge.

3. PetroBlock Framework

3.1. Scenario of Adversary Model

In our threat model, global external attacker A is considered in opposite to blockchain-based payment platform that performs the following categories of attacks, such as replay attack, impersonation attack, key attack, Sybil attack, false data injection attack, tampering attack, modification attack, man-in-the-middle attack, and hiding blocks attack [32].

• Key attack: This attack exploits the private key leakage vulnerability over a smart car network.
• Replay attack: An adversary tries to intercepts and then replay a valid data transmission over a smart car network. This attack can be used to deceive financial institutions by duplicating transactions, allowing the adversary to withdraw money directly from their victims’ accounts.
• Impersonation attack: Under this attack, an adversary tries to masquerade as a legal user for doing some unauthorized transactions in the blockchain.
• Sybil attack: By frequently interacting in the smart car network, an adversary can form various fake identities using some cars’ reputation.
• False data injection attack: For making smart cars take wrong control decisions, an adversary injects false data wherein data integrity associated with the control system may get compromised.
• Tampering attack: Under this attack, an adversary uses the leakage of the private key or 51% vulnerability to tamper with the amounts, transactions, and other information in the ledger.
• Modification attack: This type of attack consists of modifying the blockchain operation, such as the consensus process.
• Hiding blocks attack: In this attack, only those transactions are displayed, which he holds a positive image and disguises those that have a negative reputation.
• Man-in-the-middle attack: Under this attack, an adversary exploits 51% vulnerability, or the private key leakage and identities of two parties are spoofed in the network of a smart car then modify the transmitted data.

3.2. Scenario of Proposed Blockchain Platform

Figure 2 represents the conceptual model of the proposed privacy-preserving blockchain-based payment strategy for fueling smart vehicles in a smart pump. The design platform will manage and update the entire payment mechanism of a smart car’s fueling, storing data related to car users, smart pumps, and a smart car. The PetroBlock data lake serves as an individual property, which is also known as a stored-off blockchain. It is an essential tool employed to conduct assessment analysis like visualization, analytics, and data reporting related to a smart pump and smart car. Furthermore, the pump manager can also access a car user’s data by taking a car user’s permission within the network. In these permissions, access control policies are defined in the smart contract so that integrity and privacy related to user’s data can be maintained. The proposed system comprises nodes that manage the consensus protocol’s execution to maintain the distributed ledger’s consistency. Initially, the smart car user initiates the request of refueling to the smart pump. In response, the smart pump validates the request. On successful validation, the refueling process starts. Once the refueling is completed, the smart car user receives the payment notification. The designed system automatically pays for the refueling once the user grants permission. The successful payment notification is sent to both smart pumps and smart car users.

Mutual authentication is executed when the car user sends a refueling request to ensure end-to-end secure communication between the car user and the smart pump. Both parties employ the elliptic curve encryption to generate their temporary private and public keys (i.e., keys that are valid for one session), as in [33]. Then, each party executes the Diffie–Hellman key exchange to compute the shared session key, and hence a session key is established. The session is terminated when they receive a successful payment notification.

Similarly, in Figure 3, the submitting clients reside in the blockchain network to invoke a smart contract and receive a notification on adding a new transaction in the blockchain ledger. The participating networks belong to the business network having permission to submit transactions and maintains assets. The assets can be used in the smart contract to acquired data from sensors. The sensing data are then utilized in various methods for different tasks like paying refueling charges and car maintenance. The newly generated instance of participants and assets are stored in the respective registries. This study considers mapping the identities of participants by employing an enrollment certificate stored by the identity registry. New mappings between identity registries are created when the admin bounds an identity to a participant.

3.3. PetroBlock System Architecture

The distributed ledger technology of blockchain enables the storage of information while mainlining data privacy and integrity. The system architecture of the proposed PetroBlock is illustrated in Figure 4. The proposed application contains different services like data sharing, smart pump management, secure payment transaction, smart car management, and user identity management. These services mentioned above use smart contracts and distributed ledger as an adapter to the application. The car user and pump manager are responsible for sending the transnational proposal through application to use the proposed blockchain platform’s services like payment of refueling, smart pump management, data sharing, smart car management, and user profile management.

The proposed system provides a secure way to transfer payments and offers the complete Create, Read, Update, and Delete (CRUD) operation on the involved assets and participants that modified the connected nodes’ data. The user manager is responsible for enrolling the valid participant and providing with enrollment certificate. The consensus manager enables the different participants to connect through the proposed blockchain application. The entity involved in the proposed system is comprised of a distributed ledger and nodes. The node’s responsibility is to endorse transaction proposals through smart contracts and store data. The data consistency is managed by a consensus algorithm, which also ensures the integrity of data. The DLT [34] can store the immutable transaction and keep the consistency of every ledger copy by using a different cryptographic algorithm.

Sustaining the copy of a blockchain and transaction processing is the responsibility of nodes in a network. An example of such a blockchain node is shown in Figure 5. The characteristics of the node include blocks, policies, state databases, and smart contracts. The ledger state at a given time is maintained in a state database. The association among block and state databases is represented via sample white box illustration. The policies decide which transaction is recorded to the ledger in terms of node agreement. Each blockchain block contains the data related to payment, user profile, and other entities involved in the blockchain platform. Each block is assigned a sequence number, aiming to identify a block’s order in the blockchain and resist hiding block attack, as in [35].

A smart contract adds functionality to a blockchain because it is a computer program that performs transactions and views the blockchain history and blocks. A distributed database is used to store this computer program. Smart contract features include validations, adding constraints, and applying business logic to the transactions. A blockchain developer may suffer from various challenges while preparing smart contracts. Smart contracts are made using new programming languages such as solidity, making the learning curve steep and hard to maintain. Moreover, the transaction’s execution has minimal performance as nodes in a network follow order during transactions. Furthermore, network concurrency and high parallelism is also attained. We employ Node.js and Java programming languages to implement the smart contract. The presented system has various functions for interaction among users and ledger. For instance, details regarding payment history, fuel storage can be analyzed by the pump manager. A smart car user can record previous refueling visits, payment history, and car consumption. A user holds complete access to CRUD operations and can query the permitted information. The smart contract-based application accepts the transaction, runs different queries on it, and then modifies the ledger state by combining the transaction in a block and giving back the amended result in the form of a response. The illustration about the ledger queries and ledger updates harnessing a smart contract is shown in Figure 6.

3.4. PetroBlock Network Structure

Figure 7 presents the network structure of the proposed PetroBlock blockchain network. The main participants are the pump manager and the car user. They can access the secure payment blockchain network with the user application by invoking the exposed REST API’s. The Membership Service Provider (MSP) is used for user authentication, signature generation, credential validation, credential issuance, and verification. The orderer service provides the interface through which peers can connect to the channel and is responsible for transaction orders. The proposed blockchain-based payment mechanism for fueling smart vehicles comprises multiple peer nodes that can endorse the proposal for a transaction or write a block of a transaction to the ledger. Each peer node consists of chaincode, endorsement policies, and storage space.

3.5. Workflow for Channel Creation and Setting Chaincode in Proposed Blockchain Network

Figure 8 presents a workflow of channel creation in the proposed PetroBlock platform. The user-like administrator submits a request to the application, which creates a fabric channel to isolate chaincode to the participating member only. This allows the administrator to add the car user and pump manager as a participant to a channel. The channel creation event requests the selected participants through a chain messaging mechanism so that the participating member’s parties can join the channel. The receiving member application accepts the channel message, then invites its peer to join the channel. Once the channel is joined, the application installs the chaincode on the peer file system. This process then allows multiple organization peers to send transactions or query the Chaincode with its state secured in the channel.

4. PetroBlock Implementation

4.1. Development Environment

The designed blockchain platform is developed using Hyperledger Fabric [8,9], Hyperledger Composer [11,13], Docker Composer, Docker Engine, and CLI tool. The configuration of the proposed system is shown in

Table 1. Development Environment.

Tools	Description
Hyperledger Fabric	v1.2
Docker Engine	Version 18.06.1-ce
Docker Composer	1.13.0
IDE	Composer-playground
CLI	Composer-rest-server
Operating System	Ubuntu Linux 18.04.1 LTS
Programming Language	HTML, CSS, JavaScript,Node.js
Browser	Microsoft Edge, Google Chrome, Firefox
External Libraries	jQuery, Bootstrap

. The blockchain platform is deployed on a Ubuntu platform that involves the Hyperledger Composer, composer-rest-server, and node. We use Ubuntu Linux 18.04 LTS on Intel Core i-5-8500 @3.2 GHz processor with 8-gigabyte memory. Additionally, we use the docker engine for configuring the docker image and container. We also use docker composer for configuring the composer-rest-server. We use Hyperledger Fabric, an open-source platform hosted by the Linux foundation for developing blockchain applications. Moreover, we also use composer-playground to develop and design the business network definition. We use composer-rest-server to create the REST API for the entities involved in the proposed blockchain platform to expose the web services.

4.2. Business Model

The Hyperledger Fabric is divided into three component, i.e., transaction, assets, and participant as shown in Figure 9. In the proposed business model, participants are the $caruser$ and $pumpManager$. Assets includes $PumpMoneyPool$, $PaymentRecord$, $Bills$, $SmartCar$, $fuel$, and $smartpump$. Finally transaction are ShareFuelBillwithCarUser, PayFuelBill, UpdateCarRemainingFuel, UpdateFuelPrice, UpdatePumpStorage, UpdateCarVisit, UpdateFuelConsumption, and UpdatePaymentInformation.

4.3. Smart Contract Modeling

In Hyperledger Composer, we use the composer-rest-server to create the REST APIs services to expose the blockchain platform’s services. In the proposed blockchain platform, we use the following services mentioned in

Table 2. HTTP request in the proposed system.

Resource	Verb	Action
/api/CarUser	POST,GET,PUT,DELETE	Smart Car User Management
/api/PumpManager	POST,GET,PUT,DELETE	Smart Pump Management
/api/PumpMoneyPool	POST,GET,PUT,DELETE	Pump Money Pool Management
/api/PayFuelBill	POST	Pay Fuel Bill to Pump
/api/Bills	POST,GET,PUT,DELETE	Fuel Bill Management
/api/SmartCar	POST,GET,PUT,DELETE	Smart Car Management
/api/PaymentRecord	GET,POST,PUT,DELETE	Payment Record Management
/api/ShareFuelBill	POST	Share Fuel Bill with Car User
/api/UpdateCarFuel	POST	Update Smart Car
/api/UpdateFuelPrice	POST	Fuel Management
/api/UpdatePumpFuelStorage	POST	Pump Management
/api/UpdateFuelPaymentInformation	POST	Bill Management

. These services consist of three parts: resource, verb, and action. The resource is the request path through which we call the services. Verb contains the type of action applied like PUT, POST, GET, DELETE on a particular verb. The action is the service modules of the proposed system.

The transaction is used to interact with the entities involved in blockchain technologies like assets, participants.

Table 3. Transaction and event definition of the proposed blockchain platform.

Component	Type	Role
Update Fuel Payment Information	Transaction	Update fuel payment Information (e.g., price, date, car_no)
Update Pump Fuel Storage	Transaction	Update fuel storage information (e.g., currentFuel, remainingFuel)
Update Fuel Price	Transaction	Update fuel Price
Update Car Fuel	Transaction	Update car fuel tank level after refueling
Share Fuel Bill	Transaction	Grant access permission
Share Fuel Bill	Transaction	Grant access permission
Pay Fuel Bill	Transaction	Pay fuel bill after refueling
Update Fuel Payment Information Notification	Event	Notified that the payment information has been modified
Update Pump Fuel Storage Notification	Event	Fuel level notification has been sent to pump manager if fuel drop or increased from required level
Update Fuel Price Notification	Event	Price notification has been sent to car user
Update Car Fuel Notification	Event	Notification has been sent to car user after refueling
Share Fuel Bill Notification	Event	Notified that the specific record permission has been successfully granted to car user
Pay Fuel Bill Notification	Event	Notification has be sent after paying refueling bill

mentions the transactions and events defined in the proposed blockchain-based payment mechanism for fueling smart vehicles. Transactions are defined to provide extra functionality to the user of the system through REST APIs. Events are also part of a transaction and notify the system user if the user application triggers a specific transaction.

4.4. Distributed Ledger Storage Structure

This section encompasses details about the structure of the ledger from the presented blockchain platform. The system is split into two parts: (1) blockchain and (2) world state. The current state is another name of the world state in which a ledger state’s present values are kept in a database. The proposed system improves the transaction processing performance as traversing of the transaction log is not required. Apache CouchDB state database supports rich queries for smart contract data modeling in the form of JavaScript Object Notation (JSON). To execute content-based JSON queries in CouchDB, data must be modeled in JSON format. The query methods like getting, delete put in combination with a state key are supported by the format. This allows the invoking of smart contracts by the application by using simple APIs. As shown in Figure 10, one record is stated in the ledger, i.e., record1 of CouchDB having value for a key. A simple state value is supported by the CouchDB having only a complex state value and key-value pair having various other key-value teams.

4.5. Execution Results

This section provides some snapshots to describe the functionality of the proposed system. In Figure 11, the pump management dashboard is illustrated, which contains the pump’s information. The web form allows the user to add a new pump in the system, update pump information, update fuel price, share fuel bill, and pump money pool. The $AddNewPump$ contains information like PumpID, PumpName, NoOfUnit, FuelCapacity, and ManagerID. The $updatepumpinformation$ updates the information regarding pump manager and fuel capacity. The $PumpMoneyPool$ manage the related monetary transaction in the proposed system like total sales of the day, and payment paid by the card for refueling. The proposed pump management dashboard offers the complete CRUD operation related to the pump services, as mentioned in Figure 12.

The $updatepumpinformation$ in Figure 12 is used to modify the current pump information via invoking a request to the blockchain platform. The accurate request to the system repopulates the updated information on the user information. The information like pump manager and fuel capacity will be updated from composer-rest-server after a successful response.

Figure 13 shows the dashboard of smart car management contains the web form related to car management. The system allows the portal to add new cars, update car visits for refueling, update fuel consumption, update car remaining fuel, pay fuel bills, and update fuel payments. The $AddCar$ feature allows the system to add a new vehicle in the system after a successful transaction. The $updateCarvisitforRefueling$ is used to update the time and date of car visit for refueling. The $UpdateFuelConsumption$ is used to update the smart car’s fuel consumption by updating parameters like No_of_KM_PerLit(Number of km per liter). The $UpdateCarRemainingfuel$ allows the user to update the car fuel after refueling. The user may modify the current information by sending a request to the blockchain. The client interface will repopulate the updated information. $PayFuelbill$ transaction is used to send fuel bills after refueling. The fuel bill will be calculated by multiplying the price per liter by the number of liters refueled in a car. The $UpdateFuelPayment$ updates the existing information by sending a request to the proposed blockchain system, and after a successful response, the data are repopulated on the user interface.

5. Performance Evaluation

The designed platform is evaluated through Hyperledger Caliper [13], which is an open-source benchmark tool available for blockchain platforms. To evaluate the performance of the blockchain-based system, the Linux Foundation has developed Hyperledger Caliper. The designed model’s performance is evaluated for transactions per second, resource utilization, and transaction history. Like transaction latency and transaction throughput, the performance parameters also indicate resource allocation (memory utilization, CPU consumption, I.O., etc.).

Table 4. Environmental setup of Hyperledger Caliper.

Component	Description
Docker Engine	Version 18.06 -ce
CLI Tool	Node-gyp
Docker-Composer	Version 1.130
Node	v8.11.4

illustrates the environmental setup of Hyperledger Caliper.

The latency and throughput are the two parameters used to analyze the performance of the designed clinical trial service platform. The throughput, also known as transaction per second, is segregated into two sub-groups, such as transaction throughput and read throughput. The transaction throughput is a valid transaction executed during a defined time period, also known as transaction per second (tps), as shown in Equation (1).

$$\mathrm{Transaction}\mathrm{per}\mathrm{second}=\frac{\mathrm{Successful}\mathrm{Transaction}}{\mathrm{Time}\left(\mathrm{Sec}\right)}$$

(1)

Furthermore, the tps is measured using all nodes across the entire blockchain. Similarly, the read throughput is calculated as a total count of read operations in a specifically defined time known as read per second (rps) as shown in Equation (2).

$$\mathrm{Read}\mathrm{Per}\mathrm{Second}=\frac{\mathrm{Read}\mathrm{Transaction}}{\mathrm{Time}\left(\mathrm{Sec}\right)}$$

(2)

The proposed clinical trial service framework is evaluated in terms of latency, such as read and transaction latency. The read latency is the total round trip time between the send request and receives a response as computed in Equation (3).

$$\mathrm{Read}\mathrm{Latency}=\mathrm{Request}\mathrm{response}\mathrm{time}-\mathrm{Request}\mathrm{time}$$

(3)

Similarly, the transaction latency is the total time to authenticate a transaction, including the consensus algorithm’s processing. In the developed system, we also defined the network threshold used to define the time to commit the transaction. This paper has used Practical Byzantine Fault Tolerance (PBFT); therefore, the network threshold is set to a hundred. The mathematical formulation of transaction latency is a calculation using Equation (4).

$$\mathrm{Transaction}\mathrm{Latency}=\mathrm{Transaction}\mathrm{commit}\mathrm{time}\times \mathrm{network}\mathrm{threshold}-\mathrm{Request}\mathrm{time}$$

(4)

5.1. Simulation Results

Figure 14 shows information regarding transactions per second (tps) for the proposed blockchain platform. Here tps is deemed like throughput. The proposed model is evaluated by considering different groups. The group is split into three classes, including the number of students as 300, 500, and 1000. The first phase is investigated for the throughput from 300 users. Similarly, 500 users are considered for the second round and 1000 users for the third round. As we have seen the average throughput, the more the number of users, the better the system will perform. As demonstrated in Figure 14, the user-group with 300 users, the average transactions are 30 for the elapsed time of 100ms. However, the value for tps increases by 20 transactions per second if the number of users increases to 500. Finally, with the user-group with 1000 users, the average number of transactions are 56.

The latency of executing the proposed system’s invoke transaction having three different sub-classes for minimum and maximum, and average latency is investigated and shown in Figure 15. The categories for user-group are comprised of 300, 500, and 100 users. The average latency for the group of 300 users is reported as 2709 ms. Similarly, the group of 500 users attained an increased value of latency, i.e., 2820 ms. The latency value reaches 2984 for 1000 users. This behavior illustrates that the average latency increases as the number of users increases; however, there is a minor difference between the three groups’ latency values. Furthermore, the group with 300 users has the minimum latency compared to the 500 and 1000 users group. It is observed from the graph that the latency of the group with 1000 users increases linearly until the elapsed time of 29.11.4 ms after the proposed model converges into a stable state.

The latency value, obtained by executing a query function for three different user-groups, is shown in Figure 16. The average latency value for executing query transactions for a group with 300 users is 256. Similarly, the average latency values are 327 and 450 for user groups with 500 and 1000, respectively. We have observed that minimum latency values for 300, 500, and 1000 users are 68, 71, and 97, respectively, and the maximum latency values for 300, 500, and 1000 users are 378, 455, and 850, respectively.

Hyperledger Caliper is employed to assess the resource utilization of the blockchain network in five iterations. The resource utilization results are expressed in terms of maximum and average memory and central processing unit (CPU) usage rate as illustrated in

Table 5. Resource utilization analysis of the proposed system.

Type	Name	CPU (max)	CPU (avg)	Memory (max)	Memory (avg)	Traffic In	Traffic Out
Process	local-client.js	14.64%	8.76%	105.2 MB	90.5 MB	-	-
Docker	peer1.pump1.com	12.44%	5.59%	106.6 MB	98.5 MB	1 MB	421.3 KB
Docker	peer0.pump2.com	17.09%	6.24%	105.7 MB	96.7 MB	1.6 MB	666.7 KB
Docker	peer0.pump1.com	15.02%	4.56%	89.5 MB	82.3 MB	697 KB	287.6 KB
Docker	peer1.pump2.com	0.00%	6.54%	112.8 MB	105.8 MB	819 B	0 B
Docker	orderer.com	14.95%	6.75%	93.6 MB	88.7 MB	5 MB	5.6 MB
Docker	ca_nodeDepartment1	0.00%	0.00%	5.5 MB	5.5 MB	546 B	0 B
Docker	ca_nodeDepartment2	0.00%	0.00%	0 B	0 B	0 B	-

. The average CPU utility was captured as 5.77% and memory usage rate at 97.37 MB for the peer. The average CPU utility was captured as 1.25% and memory usage rate at 26.5 MB to the peer for the ordering node. Similarly, the average CPU utility was captured as 0% and memory usage rate at 5.5 MB for CA node. The outcomes of resource utilization reveal that the blockchain network holds a declining rate of resource occupation, increased reliability, and a promising user experience.

5.2. Security Analysis

We analyze the security of PetroBlock against the following attacks:

• Key attack: PetroBlock uses elliptic curve encryption to generate the key pair, and the attacker cannot compute the private key as solving the elliptic curve logarithm problem is difficult which ensures the key security. In addition, a different temporary private key is generated for each session agreement between nodes. In this way, the leakage of one private key will not affect: (a) during the session, the attacker cannot compute a session key of an already established session between two nodes, and (b) after the session is terminated, the leaked private key becomes useless.
• Replay attack: PetroBlock employs a separate temporary private key for each session agreement between nodes. As private keys have bounded lifetime, the replay attack cannot succeed and can be easily detected.
• Impersonation attack: This attack could only be successful if the attack can obtain the private key. As PetroBlock uses elliptic curve encryption and a separate temporary private key for each session agreement, this attack cannot succeed.
• Sybil attack: There are various ways to mitigate the effect of Sybil attack on PetroBlock: (a) raise the cost of creating a new identity. This resource requirement limits the number of attackers that attempt to create fake identities, (b) adoption of two-factor authentication mechanism, or (c) collecting the I.P. and MAC addresses of participants, which allows detecting those who have different identities that map to the same address.
• False data injection attack: In blockchains, consensus algorithms are executed before validating the records. Each node can verify the integrity of the received record when a positive consensus is reached.
• Tampering attack: Public key cryptosystem is used to encrypt and sign the transactions. This means that a tampering node cannot tamper with the transaction as it does not have the private key of the signer node. In addition, as shown above, PetroBlock is resilient against key attacks, and hence, the private key cannot be exploited by adversaries.
• Modification attack: As shown above, this attack is not possible as adversaries cannot exploit the private keys.
• Hiding blocks attack: In PetroBlock, each record has its sequence number. The requested vehicles must provide their records in case others request them. If any node refuses to provide records, it will be isolated, and no one will interact with others.
• Man-in-the-middle attack: PetroBlock ensures mutual authentication among nodes, as it uses temporary private keys for each session agreement, and hence it can prevent man-in-the-middle attacks.

6. Comparison and Significance

This section encompasses details regarding the comparison of the proposed system with contemporary state-of-the-art studies. To ensure the validity and efficiency of the proposed model, we carried out a benchmark study. The results obtained via evaluation are illustrated in

Table 6. Comparative analysis of proposed PetroBlock framework with existing platforms.

Approach	Native Cryptocurrency	Client Supported	Required Mining	Smart Contract	Device as Node	Access Policy	Consensus Mechanism
[36]	✓	✓	✓	✗	✓	Permissionless	Every Nodes
[37]	✓	✗	✓	✓	✗	Permissionless	Every Nodes
[38]	✓	✓	✓	✓	✓	Permissionless	Every Nodes
[39]	✗	✓	✗	✓	✗	Permissionless/ Permissioned	Arbitrary Nodes
[40]	✓	✓	✓	✓	✓	Permissionless	Every Nodes
[41]	✓	✓	✓	✓	✓	Permissionless	Every Nodes
PetroBlock Framework	✗	✓	✗	✓	✗	Permissioned	Arbitrary Nodes

.

Following are characteristics that have been considered to compare the proposed study with existing studies. It can be seen in the table that the study [39] holds very identical characteristics to our proposed approach; therefore, we have drawn a comparison of this study with the proposed study. A similar simulation environment to [39] is chosen for comparative analysis. During a simulation, a network of 50 peers was selected, and the simulation ran for 60 seconds that executed 960 transactions. The time cost of verifying a new block in the network forms a processing time metric. Figure 17 shows the results of the simulation for the evaluation of processing overhead. It can be seen in the graph that our study has resulted in less overhead than the other approach when a number of blocks varied from 10 to 60. Overall, the proposed study reduced 23% of the processing time.

Most of the systems have been formed on a permissionless blockchain network that allows participants to participate anonymously. This indicates that these systems do not have the confidentiality of contracts and transaction data. These systems address this non-confidentiality problem by issuing their own token to fuel smart contract execution. Adverse association with cryptocurrencies can have a major impact on transaction cost and speed. Additionally, it prevents interaction with other distributed systems since then tokens should be unified. On the other hand, our proposed approach is designed on a permissioned network due to which participants are unable to introduce malicious code via smart contract. All participants are aware about each other and all actions are captured in the blockchain as per endorsement policy that was formed for transaction type and network. Moreover, various contemporary systems do not have resource-constrained IoT devices because they have time-consuming mining due to full node deployment on these devices. However, the integration of IoT with blockchain has always suffered from resource-constrained architecture as consensus algorithms are limited to function within these constraints. Some of the existing studies deploy heavy consensus algorithms on the devices that are components of the IoT system, like gateways. However, these IoT gateways have limited storage space. Many existing platforms do not have a facility for lightweight nodes, and full nodes’ deployment must be done on gateways for verification of blocks and transactions. Moreover, this results in making gateways target as they serve as a bridge among the internet and devices. Unlike these systems, our proposed model provides a lightweight solution that mitigates the need to integrate blockchain technology and IoT devices. In addition, it does not require modification of these devices. We have incorporated blockchain as an external entity in order to have secure and reliable storage. Moreover, there is no need to download the entire blockchain network to validate transactions of IoT devices. The proposed system can play an effective role in various IoT scenarios having the limited capability. Additionally, our service APIs are used as a cross-platform to enable communication among blockchain networks and IoT devices. This study also provides the feasibility of integration with other contemporary systems.

This paper has considered a real-life case study for smart space executed during the experimentation phase to evaluate the proposed system’s effectiveness. The proposed system has specifically considered that the model can easily be extended to fulfill other domains like data marketplace, energy trading, and supply chain. For instance, the proposed model may be extended in the food supply chain network as blockchain provides reliable and traceable functionality. IoT sensors can play an effective role hereby being placed on a food item such as fish relegated for transport and remotely sensed data like humidity, temperature, and location. All food processing phases, such as digital compliance information, test results, and audit certificates, may be captured and stored in a blockchain network by enabling access to a shared ledger among all the supply chain parties. The dire need of having an IoT blockchain application with a permissioned network, user-friendly interface, and architecture, no currency exchange, high transactional throughput has been focused on in this study.

7. Conclusions

This paper has presented PetroBlock: A novel blockchain-based payment platform that allows to refuel smart vehicles in a smart pump in a privacy preserved manner. The system has employed Hyperledger Fabric for the said purpose. We have harnessed a smart contract for providing a secure payment transaction for refueling. The model presents a proof-of-concept application using blockchain technology, which maintains a record of all the refueling payments in a decentralized manner. We have employed Hyperledger Fabric, which is permissioned blockchain architecture which provides modular, scalable, and secure foundation for PetroBlock framework. Moreover, we have carried out several experiments in order to evaluate the Petroblock framework performance by using Hyperledger Calliper in terms of resource utilization, latency, and throughput. The result yields that harnessing blockchain technology enhances the performance of the proposed platform. In future, we have aimed to test the interoperability of the designed Petroblock framework with the other IoT-blockchain platform. Moreover, in order to enhance the performance, we are intended to utilize other consensus algorithms for improving the transaction processing rate for fast query execution.