This project was done for the Distributed Systems at University of Colorado Boulder. Popular ride sharing systems use a centralized structure where a single entity orchestrates interactions between riders and drivers. This leads to a single point of failure. As a consequence, this centralized structure raises concerns about data privacy and is vulnerable to attack from malicious users. Furthermore, as the central entity takes a certain cut of the profit from drivers who bear the brunt of the costs of gas and vehicle wear and tear. The propose solution to this problem is DeRiS, (De)centralized (Ri)de (S)haring. DeRiS is a decentralized ride sharing solution based on the Ethereum Blockchain.
The open-source and well documented ethereum blockchain is ideal for development given the large community it has and widespread support. Many existing tools and frameworks for development already exist, making the overall development process cleaner and easier. The Ethereum blockchain works on smart contracts which are essentially pieces of code that execute transactions between the rider and the driver. The smart contract is meant to be computationally light as ever operation on the smart contract incurs a mining cost. This leads to offloading most of the computationally intensive tasks to the user device. At a high level a smart contract has to handle the following user interactions: Rider post the start and end location of the trip along with trip costs, the rider request is added to the blockchain, the Driver can now view all ride requests, the driver selects preferred rider, the rider pays the driver as the trip is completed.
A user logging in as a driver uses his/her ethereum address to do so. The application passes this information to the blockchain and the driver is put in the logical queue of users waiting for a rider. Cancellation at this time does not cost anything as the driver has not yet committed to a trip.The drivers application then queries the blockchain to get the list of active riders. The blockchain does this by finding all the users that are currently active riders who are not yet paired with a driver and asynchronously emits the rider number along with the riders pickup and drop off location to the driver application that is listening to this asynchronously. The application code subscribes to the event and is asynchronously updated every time a rider detail is emitted. This way the driver application can asynchronously collect and update the list of active waiting riders.
Once the driver picks a rider on the application, a smart contract function is called to update the blockchain of this selection. Only the rider number is used to identify riders thereby never disclosing the rider account address. The driver also send the approximate time he/she will take to arrive at the rider pickup location. The blockchain has checks to see if the caller is a valid user and if the caller is currently an active driver who is not yet matched. The blockchain uses an event to inform a rider of being picked and the time the driver has agreed to arrive at the rider pickup location. Canceling the trip after accepting and before arriving costs the driver 10 percent of the trip cost. If the driver arrives at the location and the rider is not there, the driver can cancel and the rider is charged a fee for not showing up.
After a driver has picked a rider, he/she has to arrive in the agreed time to the pickup location to not be penalized. If the driver does not arrive in the time frame he/she looses 10 percent of the trip cost which goes to the riders account. This is done to prevent bad actors from overloading the system with trips and incentives drivers to commit to trips. When the driver is in a 0.2 mile radius of the driver, he/she calls a smart contract function to inform the rider (update the blockchain) of arrival. The driver sends his/her current location to this function on the blockchain. The function checks if the driver is actual 0.2 miles away from rider and only accepts arrival if this condition is met. As solidity does not support floating point arithmetic, small angle approximation squared euclidean distance is used to estimate distance. If the driver can successfully prove arrival location inside 0.2 miles of pickup location and has arrived inside pickup time, the blochain uses an event to asynchronously inform the rider of the drivers arrival.
The driver is paid as the trip is completed by the rider one portion at at time. The blockchain uses an event to asynchronously inform the driver of the amount of money received from the rider for the amount of trip completed. There is no charge for cancelling a trip in progress but all payments from rider stops and the driver is only paid for amount of the trip completed. Once the trip is completed (all the payment is completed) both users are informed of trip completion by an asynchronous event.
A user logging in as a rider uses his/her ethereum address to do so. The riders pickup and drop off location along with the estimated cost of the trip is also passed to the blockchain by calling a smart contract function.The rider keeps waiting until picked by a driver. When a rider is picked by a driver, an asynchronous event informs the rider of being picked. The event also informs the rider of the time taken for the driver to reach the pickup location. If the rider cancels the trip before the agreed upon arrival time, the rider is charge a fee of 10 percent of the trip cost. If the driver does not arrive in the agreed upon time, there is no fee charged for cancellation and the driver pays the rider for not showing up on time.
Once the rider has been picked, he/she waits for the driver to arrive. The driver's arrival within 0.2 miles of the pickup location is informed to the rider by the blockchain using an asynchronous event. Cancelling the trip once the driver has arrived or the rider not showing up to pickup location costs the rider 10 percent of the trip cost. As parts of the trip are completed, the rider pays the driver for the portion of the trip that is completed. The blockchain checks if the amount already paid is less than or equal to the amount owed preventing overpayment. There is no charge for cancelling a trip in progress but all payments from rider stops and the driver is only paid for amount of the trip already completed. Once the trip is completed (all the payment is completed) the rider is informed of trip completion by the blockchain using an asynchronous event.
The blockchain can be evaluated on the transaction cost of each function. The transaction cost is the amount it cost to execute a segment of code on a mining device on the blockchain. While functions that just return values don't cost anything, functions that set/change contract data or execute payment cost gas to mine. All functions in the Deris smart contract incur a transaction cost. The graphs shows various transaction costs for the rider and driver functions. While the numbers look high, it is important to note that they are in wei. One either is 10 to the power 18 wei, making each transaction cost quite small. That being said, the driver and rider request have a larger amount of transaction cost compared to the other functions. This is because these functions are used to set the initial state of the users.
Another way to evaluate the blockchain will be the time it takes between the application call to the blockchain to the time the blocakchain completes execution of the function. This seems to be the bottleneck for the application as the ethereum blockchain take a long time to run each operation compared to a traditional client server model. From the figure we see that the ride and drive request functions take the most time to execute. As mention before the functions are used to set user states and thus have to do a lot of data access operations that inevitably take more time.