Get best of the week

Develop software for decentralized scooter rental. Who said it would be easy?

In this article I will talk about how we tried to build a decentralized scooter rental on smart contracts and why we still needed a centralized service.



How it all began


In November 2018, we took part in a hackathon dedicated to the Internet of things and blockchain. Our team chose scooter sharing as an idea, since we had a scooter from the sponsor of this hackathon. The prototype looked like a mobile application that allows you to run a scooter via NFC. From a marketing point of view, the idea was reinforced by a story about a “bright future” with an open ecosystem where everyone can become a tenant or landlord, all based on smart contracts.

Our stakeholders liked this idea very much, and they decided to turn it into a prototype for demonstration at exhibitions. After several successful shows at Mobile World Congress and Bosch Connected World in 2019, it was decided to test scooter rental on real users, employees of Deutsche Telekom. So we started developing a full-fledged MVP.

Crutch Blockchain


I think it’s not worth explaining what is the difference between a project for showing on stage and the one that real people will use. For six months we had to turn the crude prototype into something suitable for the pilot. And then we realized what “pain” means.

In order to make our system decentralized and open, we decided to use Ethereum smart contracts. The choice fell on this platform of decentralized online services because of its popularity and the ability to build a serverless application. We planned to implement our project as follows.



But, unfortunately, a smart contract is a code executed by a virtual machine at the time of a transaction, and it cannot replace a full-fledged server. For example, a smart contract cannot perform pending or scheduled activities. In our project, this did not allow us to implement the per-minute rental service, as most modern car sharing do. Therefore, we deducted cryptocurrency from the user after the operation was completed without the certainty that he has enough money. This approach is acceptable only for the internal pilot and, of course, adds to the problems when designing a full-fledged production project.

To all of the above, the dampness of the platform itself is added. For example, writing a smart contract with logic other than ERC-20 tokens will lead to an error handling problem. Usually, with an incorrect input or incorrect operation of our methods, we get an error code in response. In the case of Ethereum, we can not get anything but the amount of gas spent to perform this function. Gas is the currency you need to pay for transactions and calculations: the more transactions in your code, the more you pay. Therefore, to understand why the code does not work, you first test it, simulating all possible errors, and hardcode the spent gas as an error code. But if you change your code, this error handling will break.

In addition, it is almost impossible to create a mobile application that works with the blockchain honestly, without using a key stored somewhere in the cloud. Although honest wallets do exist, they do not provide interfaces for signing external transactions. This means that you will not be able to see the native application if it does not have a crypto-wallet built in, to which users will have little trust (I would not trust). As a result, here we also had to cut a corner. Smart contracts were delivered to the Ethereum private network, and the wallet was cloudy. But despite this, our users felt all the “charms” of decentralized services in the form of a long wait for transactions several times per rental session.

All this leads us to this architecture. Agree, it is very different from what we planned.



Ace up your sleeve: Self-Sovereign Identity


You cannot build a fully decentralized system without decentralized identification. Self-Sovereign Identity (SSI) is responsible for this part, the essence of which is that you throw out a centralized identity provider (IDP) and distribute to the people all the data and responsibility for them. Now the user decides what data he needs and with whom he will share it. All this information is on the user's device. But for sharing, we need a decentralized cryptographic evidence storage system. All modern implementations of the SSI concept use blockchain as storage.

“What has the ace up my sleeve?” - you ask. We launched the service for an internal test on our own employees in Berlin and Bonn, and we faced difficulties in the face of German unions. In Germany, companies are prohibited from monitoring employee movements, and unions control this. These restrictions put an end to the centralized storage of user identity data, since in this case we would have known the location of the employees. At the same time, we could not check them because of the possibility of hijacking scooters. But thanks to Self-Sovereign Identity, our users used the system anonymously, and the scooter himself checked the availability of a driver’s license before starting the rental. As a result, we kept anonymized user metrics, we did not have any documents or personal data: all of them were stored on the devices of the drivers themselves.Thus, thanks to SSI, the solution to the problem in our project was ready even before it appeared.

The device threw problems


We did not implement Self-Sovereign Identity on our own, as this requires expertise in cryptography and a lot of time. Instead, we took advantage of the product of our partners Jolocom and integrated their mobile wallet and services into our platform. Unfortunately, this product has one significant drawback: the main development language is Node.js.

Such a technological stack very much limits us in the choice of iron built into a scooter. Fortunately, at the very beginning of the project, our choice fell on the Raspberry Pi Zero, and we took advantage of the full-fledged microcomputer. This allowed us to run the bulky Node.js on a scooter. In addition, we got monitoring and remote access via vpn using ready-made tools.

Finally


Despite all the “pain” and problems, the project was launched. Not everything worked as we planned, but it was really possible to ride scooters by renting them.

Yes, we made a number of mistakes in the design of the architecture, which did not allow us to make the service completely decentralized, but even without these errors we would hardly have managed to create a serverless platform. It's one thing to write another crypto pyramid and quite another is a full-fledged service in which you need to handle errors, solve border cases and perform pending tasks. Let's hope that recently appeared new platforms will be more flexible and functional.

More articles:


All Articles