This document describes in some detail how an Ethereum based ridesharing distributed business could work. It will provide a workable, reasonably detailed description for the general public and define specific areas of concern and discussion on governance and law with a distributed business.
For this document, I assume the Ethereum network has evolved such that it can handle global transactions in large quantities with no appreciable delay. I assume the Ethereum network works as it is planned to eventually work.
An Ethereum based distributed rideshare program is possible and feasible, though it will not have significant difference against existing private companies. The process for both riders and drivers will be largely similar to existing processes. The drivers will set their own fares, independently. They may form associations that will seem similar to taxi companies, but any driver can leave the group at will. These associations may have a local management group allowing collective communication, dispute resolution and advertising. Privacy may be a concern. As the name of the rider and the ride details can be retrieved by anyone from the blockchain. Future encryption may resolve this.
The Business – Rideshare Program
We will describe a rideshare program with capabilities similar to the rideshare programs that exist today. The biggest difference is that the private company (such as Uber or Lyft) does not exist and is replaced by software interfacing with the Ethereum network.
I will not go into software in detail or the Ethereum transactions in details. I will focus on real-world description, and governance.
Before starting the transaction, the rider will have registered and determined a payment method. Ideally it would be directly in ETH (the currency of Ethereum) but they could also register a normal credit card or debit card in their local currency. Using their local currency would have higher fees than using ETH, but no higher than the fees of a credit card on an existing ride share program.
The rider determines the pickup point and destination, checks the fare estimate and requests a pickup. A difference between this distributed rideshare and commercial rideshare that exists today is that each driver is able to charge a different fare. This means that the rider may be able to choose the driver that suits their needs. They may see a selection of estimates, with the rating and car type. They might tell the software to always choose the lowest fare or a mix of lowest fare and best rating. It will be interesting to see how the software will adopt to this different dynamic.
At this point, the core program informs the driver to make the trip and the driver confirms acceptance. Before the ride starts, the core program would place a hold on the rider’s funds and make an initial Ethereum transaction. The record would have potential contents as indicated in Table 1 below;
This record brings up an interesting privacy element. Every Ethereum transaction is public, immutable (cannot be changed) and thus auditable. For the contents enclosed many people would consider this too public. This is discussed below under Issues at greater length.
Now the trip actually takes place. This will happen in a manner similar to today. Nothing special here.
After the completion of the trip the final financial transaction takes place. Rather than holding funds, the permanent transfer takes place. The rider and driver rate each other and the final blockchain record is entered. A printed receipt would have all the tax numbers and an Ethereum transaction reference.
From a simple software perspective view the rideshare business is made up of three software elements; the riders app, the drivers app and the core rideshare software which will in this case be hosted by the Ethereum network.
The Riders App
This application will look fundamentally similar to applications on existing rideshare program smartphone applications. While it will talk to and Ethereum network application, the user need not notice. This could be entirely transparent to the user.
One difference might be that the user could pay using crypto currency in addition to traditional payment methods.
As discussed above, the estimates for several nearby drivers may be presented to the rider allowing them to make their own choice. The rider may choose defaults in order to automate this choice.
The Rider App will be a phone App for the phone’s operating system. It will communicate with the core app via standard internet. The Riders App is not connected to Ethereum or its blockchain.
The Drivers App
The driver’s application is largely similar to the one they would use with present rideshare programs. It is expected that a few features that would not be on the existing applications, specifically because it is a distributed business.
To register the driver must;
- Set up the fee structure (including tax allocations)
- Setting the initial price [More on these below]
Or, the driver could join an existing association. The association would already have a standard fee structure and a standard pricing structure. By joining the Association the driver would commit to follow the guidelines of the Association and get the benefits that come with it.
At its core, every driver is completely independent. The rideshare program will always allow each driver to work alone. I would expect the driver’s app to facilitate associations of drivers (like taxi co-ops).
The Core Rideshare Application
The main application has both similarities and differences to a conventional business software.
- It communicates with both the driver’s application and the rider’s application
- Holds the database of all users of the service
- Holds a database of all drivers of the service
- It performs all the financial transactions
- It holds all the rules for the transactions, such as taxes, pricing and ratings
- It controls all transactions
- It is an “Ethereum distributed application”, with all that implies (click on the definition for details).
- The software acts alone without active management. There is no company behind it.
- It location is undefined because the software will execute on a random set of the Ethereum nodes. No one can predict on which computers in the world each transaction will be executed
Ideally an Ethereum program would run fully independently. It would perform the transactions independently, consistently and in a manner considered acceptable by both parties consistently. It would do this internationally, independent of local rules.
The reality, especially for this type of application, is going to be quite different. In this section, I put forth my best estimate of a governance structure for such an application. Your comments are very welcome. Until programs like this have been tested in the real world for a period of time, these are only opinions.
The case for local organizations
If you look at most cities, their taxi companies are local. Traditionally, taxi companies are no bigger than the city or surrounding area that they operate in. Uber is probably the first global taxi company, but even they had to develop local mini local organizations in order to successfully operate around the world.
In addition, local enforcement for a ride share program is easy. Call a driver, charge him, giving him a fine as appropriate, then repeat. Since local enforcement is so easy and effective, I expect that an Ethereum based rideshare program would include local management and pay local taxes.
At its heart, a rideshare program is a transaction between people. A person gives another person a lift in their car. The interactions between the people are independent from the software. So, it makes sense that an established rideshare program would have people in each local area that can be contacted in order to mediate between the drivers and the riders. In one case, a rider may damage a driver’s car. In another case a driver may act in an inappropriate fashion towards a rider. In both cases simply giving the other a bad rating is not sufficient. Having the ability to speak to an independent voice that can mediate between the two would result many conflicts before a need for lawyers or police arises.
Tasks for these local managers could include; mediation between drivers and riders in areas of;
- Managing advertising campaigns for the drivers
- Acting as the voice of the drivers with organizations such as the local government
- Acting as the voice of the drivers to the local press
However, this local management organization would not come with the software. It would have to happen spontaneously. Let’s go over a potential scenario where a local management occurs spontaneously.
To start with, a few independent drivers begin using the Ethereum distributed application. To start with they do not pay tax on the transactions.
The local government realizes these taxis exist and are offering competition to the existing taxi/rideshare environment and that they are not paying their fair share of tax. The government begins an outreach program, trying to contact the drivers and accented with some enforcement through the local police department. The government offers to assist drivers using the Ethereum program to add appropriate taxes to their fares.
Some of the drivers realize that fighting the government won’t work. They start to pay taxes. With this the drivers begin meeting each other. They realize that a group with a logo and consistent pricing will be trusted more. They create an association where all the drivers will pay the appropriate federal, provincial and local taxes. Everyone in the group agrees to charge the same fare. They deduct a small amount of the revenue and use it for advertising, informing the public of their lower fares and wonderful service.
Based on this it is likely that some taxi drivers, especially in big areas, will join up to create associations. This will allow them to offer customers a brand name, consistent service and consistent prices.
Any association would be 100% independent of the Ethereum software. The software may facilitate its operations (allowing a unique logo through the app), but it would not be required or operated by Ethereum core software. Each driver would be able to leave the Association and operate independently without limitation from the core software.
An association may be able to limit the members ability to join, but they could not stop a driver from leaving the Association.
To maintain all the services, fee management within the core application will have to be slightly complex. At its simplest all the money would go to the driver. But, certainly other people may have to be paid.
To pay tax, the government would have to set up Ethereum addresses. These addresses would most likely have simple contracts where they would return at a minimum the tax number which would then be printed on the customer’s receipt. There would have to be multiple taxes (federal, provincial and municipal), each with potentially different payment schemes.
You should be able to add additional Ethereum addresses to which a defined amount would be paid. This could cover local management team, advertising or other costs that would be shared by various drivers. These could be a set percentage of the fare up to the address receiving a maximum amount. This would allow the local management to be paid by the drivers but only to the maximum of their salary.
Ethereum is a public blockchain. All transactions are public and auditable. While aspects such as the identity of the riders may be encrypted (via ZD-Snarks)the bulk of the data for each ride will be clearly in the blockchain. The payments to each address will also certainly be public. Audits can be easily automatic and
Advantages Over Conventional Rideshare Businesses
The primary advantage for the rider should be price. At present private rideshare companies take around 20% after tax (update, I heard 52% in Montreal). These savings will be distributed between the driver and the rider.
The drivers will be able to set their own price. If they are working very late, where there is little competition They will be able to set their price higher. When all drivers are very busy, they will be able to change their price. The profit will go only to the driver. Of course, it must be a price that riders will accept. As such, it should be an efficient marketplace.
Disadvantages over Conventional Rideshare Businesses
A commercial business, such as Uber or Lyft has several advantages. They can raise funds to assist in the growth of the company. These can be used for advertising in order to build the name. They can undercut existing service to build market share. A distributed rideshare program will not be able to advertise itself. It will be interesting to see if the word-of-mouth reputation for such a service would be sufficient for the service to spread.
Who sets the Price?
In a private company, the prices set by the company’s managers using the logic decided internally by the company. Many traditional taxi companies have the fare level set by a government committee.
In the case of a distributed rideshare program the only party that can set the fare price is the driver. The only parties involved is the driver and the rider. In the case of an association, the driver could accept price of the Association which would offer a common price. Riders might prefer this as it would offer greater consistency. However, the rider would probably not see the driver price per kilometer but only the estimation for the trip.
Drivers that are on the program just to earn extra cash might set a lower price than drivers for whom the rideshare program is their primary income. Prices could be different at different times of the day. At the time and place where there are few requirements for rides, the drivers might increase the price as there is less choice. “Surge pricing” would have to be done manually by the drivers. Even if the core application could detect a surge, it is doubtful it would raise prices on its own. The distributed software and its developers have no incentive to increase prices, while the drivers in the midst of the rush would.
It is interesting to think that the drivers’ application could display the prices of drivers in your vicinity such that you could compare your prices to your peers. Would that feature be added and what would that do to the pricing?
Setting your identity in the Riders App
When you set up rider’s app, you have to define your identity. If you will be paying in ETH, this identity must be the address of the Ethereum wallet that will fund the transaction. In many cases this will be associated with name or company, such as JaneDoe123.eth. Often this can be pointed directly at a person.
But, this is not required. If payment will be done by traditional means that the program could create a dedicated Ethereum wallet for the user. The user would never even know the wallet address. This would make the transactions on the blockchain far more confidential.
However, it will be difficult to maintain anonymity on this application because each user will be associated with a phone number, payment method and the username. At least two out of three point directly to a person unless they are actively working to conceal their identity.
Privacy on the Ethereum Transactions
As this application by definition, is on the Ethereum network it is certain that each transaction will be recorded on the Ethereum blockchain. As a minimum, the information on each transaction will include the user’s identity, departure point, destination, date and amount. When you consider this information is publicly available it is quite personal especially when every trip a person makes could be tracked.
In our existing rideshare programs, we trust the private company to maintain confidentiality. They have in their databases the identity of all of the riders and drivers and can cross reference them with all of the trips. Probably, they open their databases when properly requested to law enforcement departments already. Of course, their databases can be hacked or individual employees or managers can access the information for their own uses.
With an Ethereum distributed application, the private company no longer exists. The database of all riders and drivers and the database of all of the trips they take will be recorded on the Ethereum Blockchain. How confidential this will be encryptedmust be determined as the company and the software driving it is developed.
Legal appears pretty simple for a rideshare program. It is fundamentally a local transaction with the driver and the rider meeting each other and the transaction takes place in one locale. If their is a conflict leading to legal action it would quite likely be a clear local legal jurisdiction.
Ideal Use Case for Blockchain?
According to Vitalik’s 5 Points how well does this use case suit a blockchain application? Score 10/25, 40%. Maybe not a good application for Ethereum.