Implementation of a Secure Ride-Sharing DApp Using Smart Contracts on Ethereum Blockchain

1.1 Background

For the past few decades, Blockchain is revolutionizing every major industry with distinguishing properties and not just with the financial sectors. Researchers are trying to explore the problems where blockchain can fit in and provide exceptional services. Crowdfunding, Insurance, Healthcare, Governance, Energy are few major domains where blockchain is already progressing. For the past few years sharing economy has seen exponential growth [1, 2]. For example, Ola, Uber, Airbnb, Lyft will witness the same [3]. It enabled users to share their assets with others who do not possess them and require them. Sharing of resources will reduce wastes and promotes a lot of people to participate. However, most transactions of sharing economy applications happen on a centralized platform with a third party. The transaction can be an information exchange or payments. Centralized mode of transactions is susceptible to threats like password hacks, misusing of customer data and has increased cost and efforts in maintaining it. One of the best contributors to sharing economy can be shared transport services i.e. taxi rides. Currently, Uber, Ola, and Lyft are leading their way in ride-sharing systems. Almost all ridesharing applications use a centralized approach. But, having a centralized system in ride-sharing services has many downsides like surge fee, convenience fee, GST, payment gateway charges, etc. Thus there’s a need for better approaches. One such solution to overcome the downside of the centralized approach is a decentralized, peer-to-peer approach in the ride-sharing process.

This paper aims to provide a deeper understanding of blockchain technology and give considerations of how to integrate it into their business strategies. The paper humbly claims two-fold contribution:

1. A blockchain-based ride-sharing architecture is proposed for safe and secure traveling.
2. A prototype of the proposed architecture is developed as a Decentralized Application (DApp) on the Ethereum blockchain.

1.2 Blockchain

Blockchain is a peer-to-peer, distributed ledger technology that progressed from Bitcoin [4], a cryptocurrency developed by Satoshi Nakamoto in 2008. The overwhelming success of Blockchain is due to its distinct properties like distributed, decentralized, immutable, secured, and shared. Every transaction in the blockchain is recorded and anyone in the network can access and verify the transactions. As it follows a peer-to-peer(P2P) model blockchain eliminates the need for intermediaries. Adapting Blockchain in a smart city can lead to various benefits like security, transparency, trust-free, and automation. A smart city aims in improving the standard of living and creating a sustainable environment through Information and Communication Technology (ICT) [5]. The conjunction of Smart city and Blockchain can improve the performance, efficiency, security, and smartness of the environment. The most commonly used distributed ledger technology is Blockchain. It organizes the data into several blocks interconnected with each other. Blockchain systems are of three different types: public, private, and consortium [6]. A public blockchain is permission-less and anyone being in the network can see and make transactions, validate them and manage the shared ledger. Bitcoin and Ethereum are examples of the public blockchain. Whereas private blockchain is a decentralized yet centralized network possessed by a single entity. A consortium blockchain is also a private network that handles cross-organizational transactions.

1.3 Ethereum

Ethereum is a public and permissionless blockchain introduced by Vitalik Buterin. Ethereum is built with Turing complete programming language and overcomes several limitations of Bitcoin’s scripting language difficulty. Transactions on Ethereum are done by Smart Contracts. Smart contracts are nothing but executing some set of predefined rules when certain conditions are met [7]. Transactions in Ethereum are cryptographically signed instructions. The fee for these transactions is paid as Ether. Ether is the built-in currency of Ethereum. Apart from payment Ether is also used as a pricing instrument for running DApps in the system. Ethereum defines cost for every computation in the form of Gas. These instructions are executed by Ethereum Virtual Machine (EVM) running in every node of the network. Some of the potential domains of Ethereum are Insurance, File Storage, Market Predictions, FinTech, etc. However, one of the significant use-cases of Ethereum is Decentralized applications (DApps) which will be discussed in depth in this paper.

1.4 Smart contract

A smart contract based on the Ethereum blockchain is a cryptographic bundle that takes and processes inputs, writes outputs, and stores information. The public can access the output only when some predefined conditions are met [7]. Kevin Delmolino et al., have explained a step-by-step procedure of implementing a smart contract in their Safe Smart Contract paper [8]. The smart contracts generate bytecode at compilation and are stored in blockchain. These byte codes are run by EVM which is running in each node of the network [9]. Solidity is the most common programming language in creating smart contracts. Solidity is derived from C++, JavaScript, and Python. Smart contracts enable the solidity code to run as decentralized applications on a blockchain system. Smart contracts are considered the backbone of decentralized applications [10].

1.5 Decentralized Applications (DApp)

DApp is a decentralized application hosted on a P2P blockchain network. Ethereum hosted DApps on different domains like Insurance, Energy, Finance, Health, and many more. But, many of the DApps are only partially decentralized. As per [11], the properties of DApp are characterized as,

• Open Source: DApp codes are open source and audit from a third party is possible.
• No single-point Failure: Due to its decentralized nature no central point of failure.
• Consensus: To enable transparency consensus among the nodes is inevitable.
• Currency Support: Internal cryptocurrency is the major factor that runs the ecosystem of any decentralized application.

Key differences between centralized web applications and decentralized blockchain applications are shown in Table 1 below.

Table 1. Web App Vs DApp

1.5.1 DApp architecture

DApp is two-tier architecture, one tier being the front-end client-side application and the other being the back-end server-side tier where the smart contract is deployed in the blockchain network. Figure 1. below shows the general architecture of the decentralized application and the interaction between a client and a server-side application. The tools that are used in developing the ridesharing Dapp are discussed in the later sections.

1.png

Figure 1. DApp architecture

As mentioned above any DApp has a backend and a front-end application. Unlike the centralized applications where the backend code runs on centralized servers, a DApp’s backend code is distributed through a decentralized peer-to-peer network. The front-end code of a DApp can be written in any language and API calls can be made to the backend.

Ethereum was the first blockchain-based platform to create a Turing complete language for writing smart contracts and a DApp development platform. The standard language for building DApp on the Ethereum platform is solidity. In this project, the Ethereum Truffle suite was used to develop and deploy smart contracts.

Truffle suite The Truffle suite comprises several components that are needed for developing a Dapp. It facilitates to development, compilation, deploy and test the smart contracts. It also allows the creation of front-end user interfaces for Dapps. The three major components of the Truffle suite are 1. Truffle framework, the developmental framework where the smart contracts are created, deployed, and tested. 2. Ganache, the simulator where the Dapp’s Graphical User Interface (GUI) is developed and tested.3. Drizzle: the front end library for Dapp development.

Web3.js The client-side application is just like any other web application built using HTML, CSS, and Javascript. Web3.js is a set of libraries that enables the Dapp browser to interact with the blockchain. It also helps in reading and writing data from smart contracts, transacting ethers from one account to another, and so on. We have used Metamask in our project that includes its web3 provider in the browser. Metamask is a chrome browser extension that allows users to manage their private key and Ethereum accounts in a secured manner. It uses the Ethereum accounts to interact with websites that use web3.js.

Ethereum Virtual Machine (EVM) In an Ethereum network, every Ethereum node runs its EVM and is involved in running the same instructions of smart contracts over the entire Ethereum network.

To eliminate the issues mentioned in section 2, of the current centralized model. A decentralized approach is suggested. Blockchain as we know is a peer-to-peer decentralized, public ledger that allows transactions to happen without any intermediaries. And any transaction on a blockchain network is transparent, immutable, and secured. Therefore, adopting blockchain in ridesharing services removes the middle man and makes the transaction between the drivers and users at a reasonable cost. This attracts more users onboard and benefits them financially. S. E. Chang et al., in his work Application of Blockchain Technology to Smart City Service, mentioned that adopting Blockchain Technology in ridesharing services will make us closer to the concept of Smart City [13] as it embeds the technology within the city and adds different social dimensions for efficient allocation of resources, providing high-value services and improvising the quality of life for the public. Some of the benefits provided by blockchain technology compared to the centralized model are listed below [14].

1. Less Cost: Apparently, blockchain removes the intermediated for the information exchange and thereby slashing the costs involved in the transaction to a greater extent. Moreover, it enables the user to trust the data on blockchain than an unknown third-party.
2. Transparency: Although Blockchain is anonymous it provides transparency of the transactions at the same time. Therefore, it is always possible to trace back to the information if something goes wrong.
3. Safety: Authenticity of data is assured as all the data blockchain are cryptographically protected. It is impossible to have any fraudulent data over the network.
4. Transparency: In the blockchain, the data is available over the network and the raiding parties can have a transparent view of each other.
5. Safe Payments: Users will be able to make a safe payment directly to the drivers using smart contracts, another unique feature of blockchain.

5.1 Environment set-up

1. Tools and Libraries

Several tools and libraries are available for DApp development. However, the tools and libraries used in developing this ride-sharing DApp are briefly discussed below in Table 2.

Table 2. Tools and libraries used in ridesharing DApp

Tools and Libraries	Descriptions
Truffle Framework	Allows creating DApps on Ethereum network. Provides a suite of tools to write Smart Contracts using Solidity. Provides a framework for testing the contracts. Gives tools to deploy Smart Contracts in the blockchain. Used to develop client-side applications inside truffle.
Ganache	Runs a local instance of Ethereum. Provides sample accounts that can be used for the development and testing process.
Solidity	Object-oriented programming knowledge to write and implement Smart Contracts in Ethereum blockchain.
Web3js	Open Source JavaScript library. Provides API to interact with local Ethereum nodes.
NodeJs Server/npm	Backend server for DApp development.
MetaMask	Chrome browser extension that acts as Web3 wallet. Inserts Web3js libraries into the browser so that reading writing can be done on Ethereum blockchain
MongoDB	Core data is saved in blockchain however, to facilitate the user details and displaying dashboard details we use MongoDB.
Web Front End	HTML/CSS/JavaScript which highly uses Web3Js to access the blockchain nodes.

2. Process Flow of Ridesharing DApp

To develop the prototype of the proposed framework we make use of the local Ethereum framework, MetaMask, Web3js, Nodejs, and MongoDB. Two kinds of stakeholders are identified for this DApp i.e. the driver and the rider. Each user has different roles and responsibilities that are offered using different dashboards of the DApp. Driver Dashboard shows, i) The pick-up and Drop details of the user ii) The ride fare and iii) Payment Status whereas, the Rider Dashboard shows, i) Pick up and Drop details and ii) Ride Fare. Whenever a user detail is entered, the details are stored in MongoDB and the metadata of the credential is pushed into the blockchain. The DApp contains a front end which at the back end runs a decentralized platform. The workflow of the DApp is shown in Figure 4.

4.png

Figure 4. The ridesharing DApp workflow

3. Ride Matching Problems

One of the major problems of the P2P ridesharing system is the ride-matching problem. Any ridesharing system's ability to direct drivers to passengers in the most efficient way is a distinguishing attribute. Any flexible ridesharing system must be prepared to provide an optimal solution to ride-matching problems. Some of the algorithms which give an optimal solution to ride-matching are greedy heuristic optimization, meta-heuristic optimization, Exact formulation and heuristic solution, decomposition algorithm, and dynamic programming [16]. The DApp implemented solves the matching problem by using a min matching algorithm to match riders requesting rideshare to save total travel distance.

5.2 Matching algorithm

Matching is a concept in mathematics, graph theory in specific. Matching is a group of edges without any common vertices in an undirected graph. For this ride-sharing problem, an undirected graph is formed with passengers being the nodes and their sharing plan being the edges [17]. With a maximum matching with minimum weight algorithm, it is possible to find the best sharing plan with minimal total distance. The algorithm calculates the distance between every two passengers is defined in different scenarios. The Manhattan distance between two passengers is calculated as,

$(\mathrm{A}(\mathrm{a} 1, \mathrm{a} 2), \mathrm{B}(\mathrm{b} 1, \mathrm{~b} 2), \mathrm{d}(\mathrm{A}, \mathrm{B})=|\mathrm{a} 1-\mathrm{b} 1|+|\mathrm{a} 2-\mathrm{b} 2|)$      (1)

The five different scenarios in which the distance between each two passengers d (A, B) is defined are:

1. Pick up A and then pick-up B then drop A and then drop off B
2.  

$\mathrm{d}(\mathrm{AB})=\mathrm{d}(1)=\mathrm{d}(\mathrm{A} 1 \mathrm{~B} 1)+\mathrm{d}(\mathrm{B} 1 \mathrm{~A} 2)+\mathrm{d}(\mathrm{A} 2 \mathrm{~B} 2)$         (2)

3. Pick up A then Pickup B then drop B and then drop A

$\mathrm{d}(\mathrm{AB})=\mathrm{d}(2)=\mathrm{d}(\mathrm{A} 1 \mathrm{~B} 1)+\mathrm{d}(\mathrm{B} 1 \mathrm{~B} 2)+\mathrm{d}(\mathrm{B} 2 \mathrm{~A} 2)$        (3)

4. Pick up B and then pick up A then drop A and then B

$d(\mathrm{AB})=d(3)=d(\mathrm{~B} 1 \mathrm{~A} 1)+d(\mathrm{~A} 1 \mathrm{~A} 2)+d(\mathrm{~A} 2 \mathrm{~B} 2)$      (4)

5. Pick up B then pick up A then drop B and then drop off A

$d(\mathrm{AB})=d(4)=d(\mathrm{~B} 1 \mathrm{~A} 1)+d(\mathrm{~A} 1 \mathrm{~B} 2)+d(\mathrm{~B} 2 \mathrm{~A} 2)$        (5)

6. A and B travel on their own

$d(\mathrm{AB})=d(5)=d(\mathrm{~A} 1 \mathrm{~A} 2)+d(\mathrm{~B} 1 \mathrm{~B} 2)$      (6)

To assure the quality of sharing vehicles, the algorithm does not allow people to share vehicles if their total distance exceeds 25% more than their travel. Repeat the process below for all the passengers and find the distance.

For passenger(A)

if $d(\mathrm{~A} 1 \mathrm{~B} 1)+d(\mathrm{~B} 1 \mathrm{~A} 2)>1.25 \mathrm{~d}(\mathrm{~B} 1 \mathrm{~A} 1)$

set $d(1)$ to $+\propto$

if $d(\mathrm{~A} 1 \mathrm{~B} 1)+d(\mathrm{~B} 1 \mathrm{~B} 2)+d(\mathrm{~B} 2 \mathrm{~A} 2)>1.25 d(\mathrm{~B} 1 \mathrm{~A} 1)$

set $d(2)$ to $+\propto$

if $d(\mathrm{~A} 1 \mathrm{~B} 2)+d(\mathrm{~B} 2 \mathrm{~A} 2)>1.25 d(\mathrm{~B} 1 \mathrm{~A} 1):$

operatorname{set} ${d}(4)$ to $+\propto$

The weight of any two passengers can be: $d(\mathrm{AB})=\min {{d}(1), d(2), d(3), d(4), d(5)}$

5.3 Minimum matching

A complete graph is formulated to denote passengers and their suitable way of pooling each other once the weights of the edges are defined. The pseudocode of the minimum matching algorithm is given in Table 3. Using one of the scenarios (1) mentioned above, the matching of passengers for ridesharing is shown below. A, B, C, and D are the four passengers and are assigned some weights. The edges are marked with the way of pooling [18]. For all passengers with minimum total weight, the maximum match is pair A with D utilizing scenario 1, and pair B and C using scenario 1. The digramatic representation of rider matching problem based an greedy algorithm is given in Figure 5.

5.png

Figure 5. Riders matching problems using Greedy algorithm

Table 3. Minimum Matching Algorithm used to match rides with minimum distance

Input: a stream of data b Output: distance between the passengers          Get_dist(b)          Convert stream to data object          Get Data frame from data object          Convert Passenger count to numeric type          Filter the data for passenger less then or equal to 2          Get distance from the filtered data          return distance Input: distance between the passengers Output: minimum pooling for data points          min_matching_graph(dist)          create networkx graph object Get          Get Shape from dist object          for all i in list (n1,n2...ni) do          Add node to graph G          update Position map with distance          for all i in list (n1,n2...ni) do          for all j in list (i1,i2.....ij) do          Add edge for graph          Get label from graph object Get          Print labels          return nodes and label

4. Experimental results

The developed decentralized application is tested by running different experiments over a custom network where the Ganache was running. However, it can be tested using Rinkeby (Ethereum’s) test network as well. The cost for creating the contracts and calling the contracts is given in Table 4 below.

Several ridesharing systems are available having their own merits and demerits. A comparison of the existing centralized model with blockchain based model is tabulated in Table 5.

Table 4. Smart contract deployment cost

Contract Name	Execution Cost (Gas)	Transaction Cost (Gas)
Rider Contract	1014987	1387779
Driver Contract	1680974	2269274
Authentication	671302	939570

Table 5. Comparison of blockchain-based ride-sharing and other ride-sharing systems

5. Output

6.png