DPark: Decentralized Smart Private-Parking System using Blockchains

With the advancement in IoT technology, its applications have been widely adopted in different domains to enable smart applications to facilitate users’ lives. One aspect is the parking issue which has become a serious issue, especially in crowded cities due to a growing shortage of locations for operators to park their vehicles and a growing number of parking lots and facilities constructed to compensate. Meanwhile, homeowners and landowners leave vacant spaces that could be utilized by the enlarging population of motorists if they weren’t on private property. In this paper, we propose a Decentralized Parking system, DPark, built on top of Blockchain technology. After spot owners register their spots’ information on the Blockchain, drivers can explore owner-registered parking spots within their area that fit their needs in regard to availability, price, and location, and then book a desired spot for the price listed by the spot owner. Most importantly, all of these exchanges occur through Blockchain transactions. Blockchain provides transparency, security, and resistance to single-failure attacks. Spot owners are able to make profits from their unused space, drivers are able to find cheap and local parking, and the environment benefits from less construction of ordinary public and private parking solutions. DPark is then implemented on two different Blockchains, namely Ethereum and Hyperledger Fabric. Extensive simulations are conducted to evaluate the performance of DPark by considering the different transactions sent by drivers/spot owners at scale. Our results indicate that Hyperledger Fabric outperforms Ethereum in terms of latency and throughput, especially when the total number of transactions increases significantly. Hyperledger Fabric has demonstrated scalability up to 20,000 total transactions with high throughput of around 150 transactions per second and negligible latency. Ethereum had lower throughput of around 20 transactions per second while also exhibiting linear growth in latency relative to total transactions. Thus, these results highlight the benefit of choosing a permissioned Blockchain instead of a public Blockchain.


Introduction
One rather prevalent drawback of urbanization in modern society is the ever-increasing presence of cars, vans, and other vehicles in the most urbanized areas such as cities. When vehicle owners drive to a new location in the city, they're forced to find a new place to park which can be especially challenging in highly populated cities with lots of vehicle owners driving to their place of employment as well as social events. This is worsened when we consider the impact that an individual passenger vehicle can have on greenhouse gas emissions, with a typical gas vehicle emitting approximately 4.6 metric tons of carbon dioxide into the atmosphere per year [1]. What we're left with is a giant congestion problem on the streets as well as in designated parking areas. One study estimated around 30% of traffic in congested downtown areas is comprised of drivers looking for available parking spaces [2] and another estimating this figure to be as high as 74% [3], depending on the city and the time. It has also been shown that US citizens spend an average of 17 hours per year simply searching for parking and wasting precious time, fuel, and an average of $72.7 billion while doing it [4] One study estimates as much as 47,000 gal of gasoline are wasted per year during this time spent searching for parking in a small business district of Los Angeles alone [3].
To solve the above parking-related issues, there is an urgent need for a smart private-parking system. A smart parking system is a novel method of parking management assisted by the use of computation and/or IoT devices to make real-time interpretations and inferences about parking availability [5]. For example, researchers at the Southeast University in Nanjing, China explored the idea of a shared parking strategy for parking lots implemented with artificial intelligence [6]. With a smart private parking system, property owners can list their available and/or unused parking spaces for rent by registering the spots with the service. This can be done by providing any mutually agreed upon means of uniquely identifying a specific parking space to the parking service while also defining some key details such as the address the spot is legally associated with, the price rate that the spot should be listed for, and perhaps other optional items such as photos to help a driver easily recognize the parking space. This system enables an efficient, contactless method of providing sustainable parking within a city that also generates revenue for parking owners. Additional benefits include less time spent searching for parking (and thus less fuel usage) carbon dioxide emissions, and street congestion. Furthermore, the utilization of private space, particularly in residential areas, would more evenly distribute parking resources throughout a city in contrast to the current business-sector-heavy distribution.
To build a smart parking system, a server is needed to match requests from drivers with offers from spot owners and handle the payment between the drivers and the parking spot owners. This relationship is commonly represented and implemented using the client-server model. The client-server model involves a computer used by an individual or organization to send or request information from one or more servers in some central location. Traditionally, all of the information for the system is stored centrally on this server. However, this client-server model suffers from a number of cyber-attacks including denial of service and man-in-the-middle attacks. If the security of the centralized server is compromised, the service will be interrupted and the data can be altered, or deleted. For instance, Uber, a major ride-sharing company, has witnessed a data leakage of about 57 million users and the company paid 148 million to settle an investigation into the such a data breach. Similarly, due to hardware failure, a service outage occurred for uber-china and customers could not complete their orders [7]. With the advancement of grid computing, several technologies such as Blockchain have gained massive interest as an alternative to the traditional client-server model as it adds a layer of security, anonymity, and authenticity to this service. On the other hand, the Blockchain model involves a communal ledger of transactions distributed to every member of the Blockchain network, rather than being stored in a vulnerable, centralized location. The transactions on the ledger are validated through the execution of a consensus protocol such as Proof of Work or Proof of Stake which ensures, through advanced cryptographic algorithms, that no malicious parties are submitting faulty transactions. Therefore, users of the Blockchain are able to guarantee that information on the Blockchain is authentic since it is automatically vetted by the network. While the first instances of Blockchain were used to trade virtual currency, Blockchain can be used to host decentralized applications called Vol.: (0123456789) DApps. The business logic of these applications and other items is implemented through smart contracts which is code that lives and is executed on the Blockchain network.
In this paper, we propose a Decentralized Parking system, DPark, which leverages Blockchain technology to create a smart private parking system that uses smart contracts to define the way that parking spaces are registered, hosted, queried, and rented through a user interface. DPark aims to accomplish the goal of securely entering the private parking rental sector through decentralized means. In addition, this paper conducts a performance evaluation of DPark running atop two different Blockchains: Ethereum and Hyperledger Fabric. Ethereum is an instance of a public Blockchain while Hyperledger Fabric is an instance of a private/permissioned Blockchain. This evaluation, based on several use cases where drivers and spot owners interact with DPark, gives us insight into the efficiency and scalability of each of the respective Blockchain platforms. At 150 tps, the Hyperledger Fabric Blockchain easily handled up to 20,000 total transactions with marginal latency and high throughput whereas Ethereum has greater latency and lower throughput at only 1000 total transactions. These results indicate that based on the above metrics, Hyperledger Fabric outperforms Ethereum. This paper focuses on a practical approach to build a trusted and smart parking system architecture. Moreover, it provides a simulation and case study about the smart blockchain.
The rest of this paper is organized as follows. In Section 2, we discuss some related work in the growing body of literature surrounding decentralized smart parking systems. In Section 3, we cover the design goals as well as functional and nonfunctional requirements of DPark. In Section 4 we explain our proposed solution and the tools and technologies we used to create it, including smart contract design. Additionally, we present how this solution would adapt to an example use case. We implemented the DPark smart contracts on both the Hyperledger Fabric Blockchain as well as the Ethereum Blockchain. Next, we used Hyperledger Caliper to perform a series of benchmarks on both Blockchains and collect metrics on their performance. In Section 5, we cover the design, execution, and results of our experiment. Finally, in Section 6 we summarize our findings and interpretations and add some concluding remarks.

Related Work
Smart parking systems have gained significant attention from both industry and academia. In this section, we review related work involving Blockchain and/or smart parking systems.

Smart Parking Systems in the Industry
The past decade has produced a number of different smart parking systems. However, only recently have we seen privacy-preserving smart parking systems. Some cities, such as San Francisco, have implemented such a system with their SFpark app -a project aiming to maintain 15% parking vacancy on any given block using asphalt sensors to inform a dynamic pricing scheme [6]. Similarly, smart parking apps such as ParkMobile are beginning to become popular in the United States. ParkMobile works with cities and companies to integrate meters, payments, and processors with a real-time interface for users to view nearby available parking [8]. However, these solutions are not as approachable to individual spot owners looking to make some extra money off a small selection of parking spaces. Moreover, these systems use centralized data storage, creating a number of security and privacy vulnerabilities. A growing number of recent studies lend to the idea that Blockchain-based smart parking systems can be used to privately, securely, and efficiently manage parking resources.

Works Emphasizing Efficient Matching for Parking Spots
Considering the overuse of some parking lots and the underutilization of others, authors of [9,10] studied methods of balancing the parking demands of public and private parking lots. In [9], authors define an ADMM-based matching algorithm to map parking spots in a way that minimizes parking expenses and maximizes parking demand balancing. After running a simulation, they found their algorithm to be 8.5% better than the greedy approach. Similarly, authors of [10] aim to create a real-time parking reservation approach to better utilize available parking resources. This system uniquely employs a multi-to-one matching pattern, matching several drivers with a single space in order to efficiently schedule the matched demands of the same parking space. By applying some pre-processing constraints to reduce the solution space of the MIP model, implementing a two-stage heuristic algorithm, and simulating an experiment setting using real parking data gathered from Beijing, they found their solution capable of significantly reducing the total traveling cost of drivers while simultaneously improving the utilization of parking spaces. However, since both studies were only tested using simulations, future work requires actual implementation -perhaps using smart contracts to implement this distributed matching algorithm.

Smart Parking Systems Integrating IoT Devices
The work in [11] aims to develop a smart parking system but considers the usage of IoT devices alongside Blockchain technology. The proposed system uses cameras and deep learning for license plate recognition of cars entering the lot. This information is stored on the Ethereum Blockchain and used to track the vehicles' admission and history within the parking lot. Since they used Ethereum, the authors took care to note the gas limits and gas prices for smart contract deployment as well as function calls on the Blockchain in order to analyze the cost-effectiveness of their solution in a real-world setting. However, it does not examine the use of alternative Blockchains as a preliminary measure to increase cost-effectiveness. We hypothesize that using a public Blockchain such as Ethereum may impose increased cost relative to its permissioned counterparts such as Hyperledger Fabric.
Another system that makes good use of IoT device integration is the one proposed by the authors of [12] who also deployed their solution on the Hyperledger Fabric Blockchain. Their project was specifically aimed at tackling issues related to roadside parking management. The proposed system works by collecting dynamic parking information metadata from a variety of camera networks. After some initial processing such as license plate recognition, this information is uploaded to a web server and stored in a MySQL database. The database was implemented to reduce some of the storage (and thereby cost) overhead from storing a growing bank of information on the Blockchain. The authors also made use of the Hyperledger Foundation's Caliper tool to perform a series of benchmarks on their instance of Hyperledger Fabric. They tested all of their transactions at 1000 tps and an unknown total number of transactions or length of execution time. More indepth experimentation could have shown how their Blockchain solution reacted at scale.
Finally, the authors of [13] proposed the sharing of resources and data between smart parking systems in order to provide one-stop parking information services to commuters in a smart city. In order to address issues of trust and performance, they choose to implement this solution with Blockchain. The specifics of this Blockchain implementation were not defined and it remains to be seen how their proposed system would perform across the various layers (application, network, transaction, physical) mentioned.

Works Emphasizing Security and Privacy
Similar to our system, the authors of [14] explored the idea of renting private parking spaces. In contrast to traditional methods of renting out private spaces, they wish to achieve this in a way that ensures the anonymity of their users using Blockchain. They achieved this using the BCOS Blockchain -"a consortium Blockchain derived from Ethereum that has grown in popularity due to its accessibility for building DApps such as the one proposed. They were able to achieve the desired level of anonymity by only exposing the amount of the transaction and using the BCOS platform one-time pad and group-signature mechanisms. While successful in their goal, the paper doesn't consider the costs in terms of latency and throughput for their proposed system built on their Blockchain of choice.
Authors of [15] have proposed a smart parking system designed to achieve fairness, reliability, and privacy protection. They consider the drivers' electric vehicles as light nodes of the Blockchain that can send and receive transactions using VANET (Vehicular Ad hoc NETwork) protocols. Their Blockchain stores encrypted parking requests between drivers and spot owners in addition to handling parking spot matching based on map partitioning in order to preserve privacy. Their solution also guarantees fairness by writing smart contracts that transfer funds directly between the driver and parking owner while also punishing malicious/misbehaving users. While their time complexity analysis shows that all transactions past system initialization can be achieved in a very short amount of time with constant time complexity, it remains to be seen how long these transactions would take on a variety of different Blockchains.
Finally, authors of [16] aim to solve the problem of matching drivers with unused parking spaces with their privacy-preserving online parking sharing incentive scheme. Similar to [9,10], the authors of [16] also aim for efficient matching by using mixedinteger nonlinear programming problems to minimize the distance between a driver and a parking spot. However, this system also takes great care to preserve the privacy of its users which is facilitated by the Laplace mechanism which masks the users' location coordinates. They evaluate their proposed system using sample data from a small region in Beijing. This evaluation showed consistent and efficient spot matching as well as an acceptable amount of privacy leakage, as deemed by the writers. In the future, the authors wish to design incentive auction mechanisms with an upper bound for efficiency loss. However, they did not consider migrating to a Blockchainbased implementation to prevent cyber attacks.

System Model and Design Goals
This section addresses our system model and the criteria that must be met by the system. All references are summarized in Table 1.

System Model
The following describes the various components of the system model illustrated in Fig. 1 1. Parking Spot Owners and Drivers: Parking spot owners and drivers represent the two primary use cases of the DPark system. Parking spot owners use the DPark interface to register one or more of their available parking spaces on the Blockchain. In turn, drivers use DPark to reserve one of these available parking spaces for some specified period of time. When a driver uses the interface to reserve one of these parking spaces, that new reservation is added to the Blockchain.

2.
Frontend/Backend Server: The frontend/ backend server has three key responsibilities. Firstly, it hosts the user interface for users of the DPark system, allowing them to interact with the Blockchain in a way that is approachable and pleasing to the eye. This is achieved through use of React.js and Node.js to serve dynamic webpages to the user. Secondly, this server is also responsible for acting as a middle-man between the frontend user experience and the actual Blockchain. Finally, it allows us to install packages related to the Blockchain that can't be used by the frontend, but make development a lot easier. For example, the Hyperledger Fabric SDK [17] allows applications to interact with a Fabric Blockchain network by providing a simple API to submit transactions. This is achieved through the use of NPM to install packages, Node.js as a runtime environment for JavaScript, and

Design Goals
Using the system model defined in the above section, this section details how we intend to develop a private parking web application that meets the following design criteria:

Develop a Working User Interface
The proposed scheme shall have not only have a working backend, but a functional user interface that efficiently allows a non-technical user to interact with the system. The frontend shall be built using the React JavaScript library [18] to construct a dynamic user experience and Express [19] as a middleware, allowing the frontend to communicate with the backend. The reason we use Express as a middleware is because Hyperledger Fabric offers a Node SDK (v2.2), allowing us to interact with a simple API to submit transactions to a ledger or query the contents with minimal code.

Compare Performance of Different Blockchain Implementations
In order to speculate how different Blockchain solutions perform for this application, it's necessary to implement the same smart contracts on both Blockchains. We have selected a popular permissioned and a popular public blockchain to compare the performance and make broad observations about which type is better for applications like DPark. From there, we test the same functionality and compare the performance of each Blockchain based on key metrics such as latency, throughput, and error rate. We implement DPark smart contracts in both Hyperledger Fabric as well as Ethereum and run benchmarks on both to ensure consistency and accuracy in our results.

Proposed Solution
In this section, we discuss an example use case for the DPark application while further detailing all interactions with the Blockchain by our two users. In this example, a spot owner is a registered DPark user who is interested in listing their privately owned parking spot for other users to rent. Following this, a driver is a registered DPark user who is currently looking for parking spots available for rent so that he can find a place to park. Figure 2 shows a sequence diagram for all phases and interactions required for successful operation of the DPark system. This use case can be generalized by the following statement: a spot owner is looking to register a new spot which allows a driver to find and select said spot from a list of available spots, make a reservation, and later check in to that spot. The solution to this problem statement is broken down into three distinct phases: a spot registration phase, a spot selection phase, and a check-in phase, all of which are represented in the figure by horizontal slices. The different steps taken in these three phases are elaborated upon in the following subsections.

Spot Registration
In this phase, a spot owner is able to register one of his available parking spots with DPark. After logging into the DPark application, if a spot owner wishes to register a new spot to his account, he should first navigate to the Manage Spots page through the user dropdown. This brings him to a listing of every spot that they have listed on their account by address. They can see an option to add a new spot which, upon selection, brings them to a form for registering a new spot. This form requires the spot owner to fill in information about the spot including the precise latitude and longitude location of the spot, the address nearest to the spot (such as a home address, if relevant), the type of spot such as "Driveway" or "Street," and finally the price they would like to list the spot for initially. When this information is provided and the form is submitted, a call is made passing this information along to the registerSpot function of our smart contract. This adds the spot to a running list of spots listed on the application.

Spot Selection
In this phase, a driver is able to select the spot from a list of available spots that meet criteria based on proximity, price, and availability. Once registered in the Blockchain, the spot is ready to be reserved by a driver. The driver first checks to see all available spots to find the one that best suits their needs. Both the home page, which populates a Google map with spots, as well as the Browse page shown in Fig. 3 make a call to query all the spots. As can be seen in the DPark Contract in Algorithm 1, this querySpots function call returns a list of Spot assets which is interpreted and made readable by the frontend for the driver. Suppose that our driver sees this list of spots and selects the one just made available by our spot owner. This takes them to the webpage for the selected spot which displays more information about the spot. It also presents the driver with two dropdowns for start date/time and end date/time to populate out if they wish to reserve the spot. If there are no conflicts between the selected time range and current reservations for the spot, the driver can click a button to reserve the spot for that period. If clicked, this button makes a call to the reserveSpot function in Algorithm 1, passing along the spotID, the start and end date/time represented in milliseconds since 1970, and the userID associated with the driver's DPark account. The specific implementation of reservations differs between our Ethereum and Hyperledger Fabric smart contracts, but the concept is similar. When reserveSpot is called, a new Reservation object is created which stores the information about the

Check in/Check out
In this phase, a driver authenticates himself in order to check into the parking spot he has reserved, and check out when his time at the spot is finished. Let's assume that our driver drove his vehicle to the spot and now needs to check in so that DPark has a record of their time at the spot. The driver must select the spot that they're checking into and then click the option to check in. As shown in Fig. 4, we authenticate the driver's presence at the spot by having the spot owner print out a QR code that is generated based on the spotID, hostID, and address to represent that specific spot. The spot owner is instructed to securely place the QR code somewhere plainly visible for the driver to scan when they arrive. Once the QR code is scanned and authenticated, the checkIn function is called on the Blockchain with the spotID and the userID. When the driver wishes to check out, they simply find the reservation again and click "Check Out" which makes a call to the checkOut function.

Performance Evaluations
This section discusses the design of the experiment of the DPark system atop the two different Blockchain networks -namely Hyperledger Fabric and Ethereum. First, we explain the setup of the test environment, Hyperledger Fabric, Ethereum, and Caliper followed by defining the key metrics used to evaluate set of test cases to measure the overall performance of Dpark. Finally, we analyze and discuss the results of these experiments.

Methodology/Experiment Setup
Test Environment For developing DPark, we have used Linux Ubuntu installed on Dell XPS machine with a 2.20GHz Intel Core i7 processor. The relationship between the SDK and the Blockchain network is illustrated by Fig. 6.

Hyperledger Fabric Setup
The Blockchain network has an ordering node and two peer nodes. The network setup is well explained as given in Fig. 5. A1 represents the DPark web application connected with channel C1, configured with channel config CC1 to enable a group of participants to form the ledger (L1) while being on the same network and hosting the ordering service node O1 and two peer nodes, P1 and P2. The ordering node, O1, packs the transactions into blocks. SC1 is the smart contract that holds the business logic for the DPark application (Fig. 6).
Ethereum Setup Smart contracts are written in Solidity [20] and deployed using components of the Fig. 3 As seen in this screen capture, a driver can browse for a place to park after entering search criteria such as availability, type, and price. After making a call to querySpots(), the frontend is responsible for filtering the data based on the driver's search criteria of transactions to the smart contracts. For example, Fig. 7 and Algorithm 2 are the benchmark and workload used on the Hyperledger Fabric Blockchain. The benchmark in Fig. 7 is split up into rounds that each execute the workload at a different tps (only one round is included in the pseudocode sample). The workload, in this case for registerSpot, uses some sample data to send a request to register a new spot on the Blockchain. Worker processes, or "workers", are responsible for performing the actual workload generation, independently of each other. With our setup of Caliper, we only ever utilize a single worker. The network configuration file is used to bind Caliper to the System Under Test (SUT) which, in our case, is either the Hyperledger Fabric or the Ethereum Blockchain.
In DPark, we wrote several benchmarks and workloads for registerSpot, reserveSpot, querySpots, and getReservations. Benchmarks are divided into rounds. Each round defines the workload to be run, the rate at which the transactions are executed (rateControl), and the total number of transactions (txNumber). Caliper handles interactions with the Blockchains while the workloads write the observations on the total number of transactions that were successfully committed to the Blockchain, the total number of failed transactions, max latency, send rate (tps), average latency (seconds), min latency (seconds), and throughput (tps) to the benchmark report.

Performance Metrics and Simulation Design
Performance is evaluated using the following metrics.
-Throughput is the rate by which valid transactions are committed by the Blockchain. -Latency is the amount of time between submitting a transaction and getting a response back from the Blockchain. Measuring transaction latency across all nodes of the network ensures a more realistic timing evaluation that reflects the true latency experienced by all DPark users. -Error Rate is the total number of transactions that were not successfully received by the Blockchain divided by the total number of submitted transactions.
Moreover, using the above metrics, the following three cases were tested: -Case I. The goal of this case is to experimentally determine an optimal upper bound for the transaction rate that can be achieved with our test environment without inducing significant network issues. In this case, a fixed number of transactions is executed with a transaction rate changing from 100 tps to 300 tps in increments of 50 tps. -Case II & Case III. Using the optimal value from the above case, we studied the effect of changing the total number of transactions at that fixed transaction rate. The goal of Case II is to examine the impact that increasing the total number of transactions to very high values has on the overall performance of the Blockchain. Next, Case III finds the varying transaction rates impact and varying total transactions on the error rate.

Results and Discussion
In this section, we discuss the results of the experiments. Note that for all of the following figures, the Ethereum Blockchain latency, throughput, and error rate are colored grey, and those same metrics are colored green or blue for the Hyperledger Fabric (HF) Blockchain.
Case I Fig. 8 shows the varying transaction rates impact on both throughput and latency for both HF and Ethereum. It can be clearly seen that HF outperforms Ethereum in terms of throughput and latency. For example, when tps = 300, throughput is 200 and 20 for HF and Ethereum respectively. On the other hand, latency is in the range of milliseconds for HF in comparison to a range of seconds in the case of Ethereum.
The Ethereum Blockchain is also shown to have relatively stable throughput for both of the read and write transactions, indicating that there is no relationship between the transaction send rate and throughput for Ethereum. For Ethereum, even readonly transactions can achieve relatively high latency if more work is involved in completing the transaction. On the other hand, the HF Blockchain shows an increase in throughput as the transaction send rate increases. As a result, the HF Blockchain network can easily withstand growing send rates without compromising on the total number of transactions submitted to the ledger. The results of this case can be generalized as follows.
-For both Blockchains, average latency increases as transaction send rate increases. -For read transactions on HF, throughput increases as transaction send rate increases, at least up to a send rate of 300 tps. -Regardless of the transaction send rate, for both of the read and write transactions on Ethereum, throughput is relatively unchanging at around 17 tps (on average).
Case II Fig. 9 illustrates both throughput and latency of executing a given transaction on both Blockchain solutions plotted against 1000, 5000, Algorithm 2 Pseudocode for registerSpot workload module 10,000, and 20,000 total transactions with a fixed transaction rate of 150 tps. In both Fig. 9a and b, both read and write transaction types, transactions submitted to the HF network experienced negligibly small latency for the entire range of values. On the other hand, Ethereum showed exponential increases in latency as the total number of transactions increased (see Fig. 9a). For throughput, it can be seen that HF shows a steady state throughput (around 150) in the case of read transactions (see Fig. 9a). Meanwhile, there is a slight increase in throughput in the case of write transactions (see Fig. 9b). This is because, for write transactions, Blockchain nodes require time to verify and validate submitted transactions. Overall, the system throughput is not affected by the increasing rate of transactions up to 20,000. The results of this case can be generalized as follows: -At a transaction send rate of 150, latency on the HF network is little to none. As the total number of transactions increase, latency on the Ethereum network increases exponentially, regardless of the transaction send rate. -The throughputs of both Blockchain networks does not change so long as the transaction send rate is constant at an optimal value (150). Case III Fig. 10 shows the error rate of read and write transactions on both Blockchain solutions plotted against 1000, 5000, 10,000, and 20,000 total transactions with a fixed transaction rate of 150 tps. It seems that both Blockchain networks, Ethereum in particular, were able to execute the range of transactions with little to no errors. It can be seen from Fig. 10 that the Ethereum Blockchain shows an error rate of zero for both of the read and write transactions. In contrast, HF only had a few errors on write transactions, as can be seen with the Write Transactions of Fig. 10 where the error rate steadily lowers to roughly 0.03%. For HF, the number of errors is actually remaining relatively consistent despite increases in the total of number of transactions. This was the data seen when the transaction payload was lessened to a usable amount. It can be noted that transactions with high payloads did result in as much as 90% errors on both networks, but those results were not included. Instead, we found a workaround that involved committing the same number of transactions but in a way that lessened the payload to a more manageable amount to produce usable results. The results of this case can be generalized as follows: -Both HF and Ethereum Blockchains can handle at least up to 20,000 tx with few or no errors, respectively, relative to the overall number of transactions. -HF does not make the same tradeoff of errors for performance as Ethereum, and thus, HF does not outperform Ethereum in terms of error rate. -Payload size is largely influential on the error rate of both Blockchains. A larger payload leads to a higher probability for failing the transaction.
Case IV Fig. 11 shows the latency and throughput of executing 5000 and 10,000 total transactions at transaction rates of 150, 200, and 300 tps.
It can be seen that the latency for both 5000 and 10,000 total transactions on HF grows with each increase in send rate, but at a negligible rate. Moreover, there is not much of a difference between the latencies at 5000 and 10,000 total transactions for this Blockchain, indicating that HF is more than capable of handling up to 10,000 total transactions with the same ease that it handles lower numbers of total transactions. In comparison, there is a strong correlation between the total number of sent transactions and the latency of these transactions on the Ethereum Blockchain. It remains to be seen if this correlation is linear or exponential. The figures show large gaps between both HF latencies, Ethereum latency with 5000 total transactions, and Ethereum latency with 10,000 total transactions. For example, the maximum average latency achieved at 10,000 total transactions on HF is 27.3 seconds, as seen in Fig. 11d, whereas the minimum average latency for Ethereum with only 5000 total transactions was 104.5 seconds, as seen in Fig. 11c. Finally, it can be seen that, aside from a few outliers, the latency is less dependent on the transaction send rate and more dependent on the total number of transactions.
The results for throughput are also less than shocking. As can be seen in Figs. 11a and 11b, HF had a much higher throughput than Ethereum for all transaction send rates and all numbers of transactions. For both Blockchains, however, throughput is shown to be much more strongly correlated with the transaction send rate than the total number of transactions. For each increase in transaction send rate, HF demonstrates a higher throughput to compensate. This makes sense given that throughput is the measure of valid transactions processed by the Blockchain per second and the transaction send rate is the total number of sent transactions per second. Therefore, it is likely that this trend would continue until HF starts to encounter scalability issues and suffers from lower throughput, as is the case with Ethereum. For both 150 2  read transactions, write transactions, and both total transactions that were tested, Ethereum's throughput remains mostly stagnant across all transaction send rates. This implies that the Blockchain has already reached its scalability cap and is struggling to process as many transactions as are being submitted. The results of Case IV can be generalized as follows: -HF is highly scalable beyond 10,000 tx, as indicated by both throughput and latency. Meanwhile, the Ethereum Blockchain suffers from scalability issues as it shows high latency and low throughput relative to its HF counterpart. -Throughput on the HF Blockchain increases with the increase of transaction send rate. Meanwhile, throughput is not affected by the change of transaction rates for the Ethereum Blockchain.
Case V Fig. 12 illustrates that both throughput and latency of executing read and write transactions at transaction rates of 150, 200, and 300 tps for 5000 and 10,000 total transactions on error rate.
Where the results of Case III may have led us to believe that HF would show similarly low error rates for higher transaction send rates, the data here strongly contradicts that and confirms 150 tps as an optimal rate for this Blockchain. Particularly for 10,000 total transactions, the error rate makes a large jump after 200 tps to unacceptable levels. Whereas Ethereum would rather experience lower throughput and higher latency in order to guarantee a low error rate, it seems HF does the opposite. The reason why HF outperforms Ethereum by having lower throughput and higher latency is becasue of the underlying consensus algorithm. Ethereum is a public blockchain based on proof of work while Hf is a private blockchain that is Byzantine-based.
The Ethereum Blockchain, on the other hand, demonstrated a consistent and negligible error rate, as it had done in Case III. The results of Case V can be generalized as follows: -Ethereum makes a tradeoff of performance for low errors, whereas HF does not. -Our implementation of HF could not scale to 10,000 total transactions at a send rate of 300 tps without significant errors.

Conclusion
This paper proposed a decentralized private-parking system. The proposed scheme is implemented using two different Blockchain platforms: Hyperledger Fabric Blockchain and the Ethereum Blockchain. Then this work extensively examines the impacts of the Blockchain network workload in terms of throughput, latency, and error rate. Various use cases were tested with changing transaction send rates (tps) or both.
Using the test environment detailed in 4.1, both Blockchains were able to handle a transaction send rate of up to 150 tps while avoiding significant network delay or errors. At 150 tps, the Hyperledger Fabric Blockchain was shown to easily handle up to 20,000 total transactions with marginal latency and high throughput. Ethereum, on the other hand, experienced exponentially greater latency at each increase in total number of transactions at a transaction send rate of 150 tps. While Ethereum did maintain a fairly consistent throughput at this transaction send rate, it was much lower in comparison to the Hyperledger Fabric network.
In summary, the throughput, latency, and error rate of a Blockchain depend on the hardware configuration, Blockchain network design, test setup, the consensus algorithm (or lack thereof), and transaction complexity/payload. If the hardware were different, perhaps we would see different results. Additionally, it seems given the non-existent error rate in each case with Ethereum, perhaps that Blockchain makes a tradeoff between low throughput/high latency and minimal error rate. Regardless, based on the results gathered in this experiment, it is likely that Hyperledger Caliper would still largely outperform Ethereum based on the same metrics under any system.
That said, it is likely that the main factor that allows Hyperledger Fabric to be so much more efficient than Ethereum is the lack of a consensus algorithm. Ethereum is generally a public domain Blockchain -anyone can access and contribute to it. This means that it requires some form of consensus in order to confirm that new blocks aren't fraudulent. Like Bitcoin, Ethereum uses the Proof of Work [23] protocol to create consensus in the network, although developers of Ethereum intend to migrate towards Proof of Stake within the coming year. This protocol requires miners on the Blockchain to perform a certain amount of computation that grows with the total number of nodes on the network. Naturally, the time it would take to add a new block would increase with each new block added. Since Hyperledger Fabric is a permissioned Blockchain network, meaning it can only be accessed by users with credentials, there is no need for such a consensus algorithm. Blocks are added to the Blockchain at the speed it takes for the ordering service on the network channel to create them. Therefore, it makes perfect sense why Hyperledger Fabric is able to maintain such lightning fast speeds.
Despite this, these results contribute to the idea that Hyperledger Fabric is a more powerful and efficient Blockchain network based on these metrics. We hope these results can be used to make informed decisions about choosing a Blockchain for applications similar to our smart private parking system.
Author' Contributions Garrett Brenner and Mohamed Baza -developed the concept of the article, designed the structure of the article, analyzed the available literature, and developed the introduction and summary. Amar Rasheed and Wassila Lalouani provide project administration, validation of results, writing-review, and editing, and Hani Alshahrani and Mahmoud Badr managed writing-review, and editing, and the funding acquisition. and All authors have read and agreed to the published version of the manuscript.

Funding
The authors are thankful to the Dean-ship of Scientific Research at Najran University for funding this work, under the General Research Funding program grant code (NU/RG/ SERC/12/27).
Data Availability All data, or code generated or used during the study are available from the corresponding author by request.