This is the second installment outlining the experiences of the winning team “PlugInBaby” during the IOTA Hackathon. In the first post (found here), we describe the idea generation process. In this post, team member Rebecca Johnson goes into more detail with regards to how the team built the project and what exactly it accomplishes.
Our PoC decentralizes and democratizes access to a network of electric vehicle chargers by allowing the chargers to costlessly broadcast their status (offline, occupied, available) via 0 value transactions on the tangle. Next, using a mobile app, users searching for a charging station can query the tangle using 0 value transactions to search for tags of available stations. They can reserve a charging spot and book micro transactions necessary to pay for electricity, all using IOTA.
Using the tangle as a database makes the solution quite elegant. The protocol for sending data and value are essentially the same which removes the need for a centralized payment processing layer and allows for the DIY ethic to extend all the way to the end-user.
This approach is also flexible enough to leave room for participation by utilities and other stakeholders since the hardware and software are open-source. Improvements are welcome and anyone is free to implement the idea. The code can be found here.
Requirements & Assumptions
- We restricted ourselves to using only IOTA for implementing the database functionality. This carries the theoretical advantages of future scalability, full decentralization and zero transaction costs for messages sent to and from the tangle as well as a mechanism for machine to machine electricity purchases.
- We assumed that the API and the interaction between the charger and the car app are out of scope for the hackathon.
- Charging station vendors need to send status messages for their stations (free, in-use, offline) using 0 balance transactions to the tangle. Our back-end provides this capability via terminal inputs. Since this is just a PoC we didn’t build out an API or UI for this portion.
- A web-based front-end, a back-end connection to the tangle and an API for communication between the two needed to be built. Given this, the team split into two groups of 3-4 developers each.
The experience of the PlugInBaby team was similar to that of the Freedom Pass team. We started out by following this tutorial from Baltic Data Science and gained speed by utilizing some of the resources from the Q&A with Chris Dukakis of IOTA. After that, we connected to a
testnet node and started issuing transactions.
Like the Freedom Pass team, we also considered using a mainnet node but the issue of how to connect with neighbors was eventually a knockout criterion. This was actually due to security concerns. One of our team members had a Java Runtime Environment setup on a remote virtual machine and we considered setting up an instance of the IRI. In the end, however, we weren’t comfortable with the security risks that connecting with unknown nodes presented.
Our team member Lukasz Zmudzinski has written a great blog post on his site which outlines which Python methods we used to read and write to the tangle in greater detail. We used the Tornado web framework and asynchronous networking library for this project and wrote our own API to communicate with the front end.
Users can query the tangle for the transactions of vendors with free stations and also read dynamic pricing information. The search mechanism uses information written to tags while the state information about the charging station and the station latitude/longitude are written in the message. This information is then passed via API calls to the front-end for interpretation in the UI.
- Step 1:
The user uses a smartphone app to query the tangle for available charging stations.
- Step 2:
The user selects a charging station from the map. Each station has dynamic pricing which is shown in real-time along with the map pin when selecting the station.
- Step 3:
The user drives to the station and lets the station know that they have arrived by sending a message to the tangle.
- Step 4:
The charging station tells the app that the car is fully charged.
- Step 5:
The user’s IOTA wallet is debited and the transaction is signed by the seed stored in the app.
- Step 6:
The charger resets its status to available on the tangle and all the transactions/messages are available for verification.
What We Learned:
The PlugInBaby PoC demonstrates the feasibility of an IOTA-based search and payment app for IOTA-based DIY chargers but it is far from ready-for-use outside of the lab/hackathon. A number of issues came up which will need to be solved before this system would be appropriate for public use.
- Tags only allow for 27 characters which wouldn’t be enough to store latitude and longitude data plus a transaction ID without truncation. The team ended up using the message field to store data (location + charger status) while the tags were used to store a searchable charger identifier.
- Speed is quite limited on the testnet. Specifically, we found that the testnet confirmation times were quite long late at night (2-3 minutes) when fewer users were online running test applications. This is due to the fact that each new transaction must approve two other transactions. This approach scales well but also requires many active nodes to submit and approve transactions. As both the testnet and the mainnet grow this problem should be mitigated.
- Transaction caching was required to make the demo useable within the alloted three minute presentation time.
- While the support from the IOTA team was excellent, we noticed that the documentation, particularly regarding the phython libraries, is quite lacking. This makes development a slow trial and error process.
- Security and privacy are generally open questions within the IOTA ecosystem. The team assumed these issues to be outside the scope of this PoC. That said we raised privacy concerns regarding the possibility of API misuse and the lack of privacy often during the development process. Improved documentation and more descriptive error messages would go a long way towards making these issues easier to handle.
- Masked Authenticated Messaging (MAM), the planned Private Transaction layer, and the integration of zero-knowledge-proofs into the IOTA ecosystem are exciting areas for new research given the current limitations of IOTA in the area of security and privacy.
To sum up, the team learned a lot about the implementation of an exciting use case that really makes sense for IOTA. Is this the only way to build such a system? No. There are many other ways to find, navigate to and pay for electric vehicle charging. Many market-ready centralized systems are already up an running. Our PoC demonstrates, however, that it’s possible to solve this use case using IOTA alone which allows for the possibility of a scalable decentralized approach. This, in turn, could open up the field to many more players and provide a common system for various entities to build upon.
Here is an overview of all reports on the IOTA Hackathon’s projects:
…describes the idea and the pivot of the project
Team “PlugInBaby”: Open Car Charging Network (Part 2)
…describes the technical level and provides resources
…describes the high level of the project
…describes the technical level of the project