I've recently become quite interested in Ethereum, the decentralised software platform that uses the underlying concept of the Bitcoin blockchain to run code while maintaining trust. I've been playing around with Smart Contracts, which are modules executed by the blockchain. I'm not going to describe in detail how the system works, but there is a starter guide on the Ethereum subreddit that you can look at for more information.
During HacknRoll 2016, the idea we came up with was to make use of Ethereum to implement a ride sharing service, much like Uber. Originally, the idea was to implement service-sharing, but we felt that Uber was a prime test case for decentralization. The company has been steadily cutting its fee for drivers, and the incident during hurricane Sandy served to demonstrate the perils of centralisation in a peer-to-peer system.
Here's the first part, where I will attempt to illustrate the theory behind the system.
We wanted to build a system that was as close to a closed system as possible. The central management system would only take as much as it needed to operate, and the rest would be distributed among users. This would achieve the lowest prices that the market can bear, with a middleman not beholden to corporate motivations. The rider would pay the driver, and that was it. We immediately sketched out the basics, and you can see the overall structure below.
The most important segment is of the two contracts that exist on the blockchain. The first, called the Central Exchange, is the central system that decides the current market price per mile, and keep track of the stock (I'll explain later) and other metadata related to each consumer account. The second, called the Rideshare, connects to the exchange when needed in order to retrieve prices. This is factored into the calculation of reputation points. There are two primary systems at work here, which will be explained below.
The first problem we attempted to tackle is that of immutability. Any algorithm residing on the blockchain cannot be changed externally. It must decide to destroy itself (via an operation called a suicide
) after telling any contracts that need it to call someone else. This needs to be done by collective consensus, and for this purpose we came up with a stakeholder system whereby each user - either driver or rider - is given points of stock that correspond to how many kilometers they've ridden using the system. Stocks are issued using hashes, and are re-weighted when more stocks are issued. These stocks will decide the amount given back when the system receives a profit above a fixed amount. They will also determine your voting power in making a decision about changing the central system. The voting system is fairly complex and wasn't implemented for the purpose of the hackathon, but we are considering implementing it in the future.
In a full-fledged implementation, there will be a third algorithm on the blockchain that opens and closes possible issues for voting. Each user is given a small amount as incentive for voting, and a multiple of that when the issue is resolved if he or she is on the winning side. This incentivizes voting and disincentivizes random voting in order to collect fees.
A rewrite of the system - as we foresee it - would involve one or more users posting rewritten source code online, which will be reviewed and voted on. When accepted, the system will then draw the code and bytecode, instantiate a new version and destroy itself while updating client algorithms to point to the new version.
The rideshare system works by allocating reputation points and in-system currency to the user. For now we have made use of a custom currency, but it seems possible to implement trusted payment gateways to remove the barrier of cryptocurrency should the user so wish. Both are stored in the rideshare system, and the blockchain ensures trust and takes care of double-spending issues.
An example ride would be comprised of the following steps:
Both the driver and the user are obligated to complete the ride, as the reputation points are required to register or accept a contract on the system. They can cancel the ride at any point and receive some of these points back, but the computation will assume that they have been given a rating of zero by the other party.
In such a system, the only money being used is the amount spent on transactions. The nodes executing the contract are paid for their time and energy, but the rest of the capital in this economy resides with either the driver or the rider.