Inspiration

PeerPool was inspired by corporate giants such as Uber and Lyft, and how they are centralizing all common transactions between the common driver persona and passenger. Uber and Lyft prevent users and drives from connecting and they collect 25% of the total amount of money the passenger pays to the driver. We wanted to remove the middleman (Uber and Lyft) and develop a new application that would have all the features of Uber (and way more) and decentralize the whole process of common ride sharing platforms. PeerPool solves the problem by removing the middleman and storing user’s data such that it’s decentralized and no one can access it other than themselves. PeerPool, A Decentralized Solution to Carpooling Services, solves the problems that many corporate giants fail to address. We decentralize this service with trustles smart contracts and eliminating the middleman, and the fees that come along with them.

What it does

PeerPool allows Users to operate a ride sharing program similar to the likes of Uber or Lyft, but quite simply, in the most efficient way possible. PeerPool is a Dapp, or decentralized application, that utilizes trustless smart contracts in order to act as the intermediary for Ride Sharing. Think of it as an automated peer managed version of a middleman. Because of this, we can provide costs for Rides that have virtually a $0 middleman fee. This is revolutionary in the sense that we can sort out disputes and move legal liability away from the Gig Workers, into trustless contracts.

How we built it

We built this decentralized application with IPFS, the Ethereum Ecosystem, ReactJS, Express, Material UI, and our brains. We used the IPFS Protocol, to store our user data such that it’s decentralized and it will prevent any external sources from accessing the user’s private information. IPFS works such that when you upload a file it will generate a hash linked to that file which we can access on any IPFS Gateway. We also utilized the Ethereum Ecosystem to securely store the smart contracts that we wrote to monitor each user. The Ethereum Ecosystem was necessary for our application to fully flower as it was needed in our proof of thought for our project. We utilized ReactJS to develop our frontend for this application, by creating multiple pages for the user and also develop multiple components that will connect to our Express Backend. We used the Google Maps API to display the routes between one point on the latitude and longitude and we developed this by using a Higher Order Component that will wrap over the initial Map component that will display the route between any two given points. For our application we needed to use the Web Geolocation API that would determine the current user’s location on the decentralized web application. We used the data from the Geolocation API and the address that the user would input (their desired location) to properly route these locations. We also used the Material UI Library to style our components and properly make our application UI and UX friendly. Our backend barebone consists of express with multiple routers for every single endpoint that would call everyone a single IPFS function, and Smart Contract function.

Challenges we ran into

One of the most challenging things that we had to do was bug fix the incredibly complicated Smart Contract backend. There was so much undocumented features that we had to pratically invent from scratch, in terms of Solidity concepts. We also had to deal with the very very very bad error handling. Node and Solidity EVM errors were extremely vague and thus difficult to diagnose. Also, the infrastructure itself was a huge pain to keep track of and build. There were so many components and processes going on that we had to really focus on to make sure it all worked together. I highly recommend looking at the Git Repo and checking the contracts (Main.sol) as well as the routes folder to just see how comedical the amount of features and processes we had.

Accomplishments that we're proud of

We are really proud of developing a fully functional Decentralized Application by only being introduced to the Ethereum Ecosystem and the IPFS Protocol shortly. Our desire for the entire application was to style it off come on ride-sharing platforms but implement it with the ever-growing popularity of blockchain. This was a lot of work for a team of 4 to finish in less than 24 hours. By developing the entire application, to arguing at midnight with our team. We had overcome many challenges that were never seen once we came up with this idea. The whole proof of thought for PeerPool was that it could be decentralized and protect the user’s data and prevent the big corporate giants from hoarding this data. With only 4 members on our team, we had delegated our team to have two people on the frontend, and two people on the backend. Our group and I are very proud of our final solution and we would’ve never seen this application to fully function.

What we learned

During this 24 hour hackathon, our team went through many challenges and overcame most of them. Let's start off with our main smart contract that was written in Solidity. Solidity’s syntax and language was built in such a way we cannot loop through the keys in a hashmap. Because our application stores all of the users on a hash map, it was NECESSARY for us to loop through all possible drivers and send them to the passenger. We need to code our own function to do this, and it allows us to access any key value pair in the hashmap. Next we implement the InterPlanetary File System Protocol, or IPFS, which utilizes the Peer-2-Peer network methodology of decentralized file sharing. We used this to update the drivers that updated their cars, and locate the latitude and longitude of our users and store it in a decentralized manner. None of us had that much experience with IPFS, but through grit and hard work we overcame this challenge with a fully functional decentralized system. Lastly, the most important concept that we learned was to call Smart Contract functions from the front-end. We had enough experience with calling Smart Contract functions in the backend, but since we needed the current user’s balance to transfer the ether, we needed to call it through the injected Web3 in the frontend. This task was very difficult, as it took away 3 hours of time and all 4 members on our team were working on this. All in all, we learned a lot through this hackathon regarding smart contracts and the IPFS decentralized protocol.

What's next for Decentralized-Uber

The application that we built with blockchain technology performs some functionality, but since we couldn’t launch and deploy it to the main network (which would cost some of our own money), it would be the next main thing for PeerPool. We would’ve also loved to add a history feature for our users, so they can review their previous transactions and possible refund them.

Built With

Share this project:

Updates