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.
History in brief
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 start the scooter via NFC. From a marketing point of view, the idea was reinforced by the story of a “bright future” with an open ecosystem where everyone can become a tenant or landlord, all based on smart contracts.
Our stakeholders really liked this idea, and they decided to turn it into a prototype for demonstration at exhibitions. After several successful demonstrations at Mobile World Congress and Bosch Connected World in 2019, it was decided to test the scooter rental with real users, employees of Deutsche Telekom. So we started developing a full-fledged MVP.
Blockchain on crutches
I don't think it's worth explaining what the difference is between a project to be shown on stage and one that will be used by real people. In six months, we had to turn a crude prototype into something suitable for a pilot. And then we understood 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 in the following way.
But, unfortunately, a smart contract is a code that is 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 actions. In our project, this did not allow us to implement a per-minute rental service, as most modern car sharing services do. Therefore, we deducted the cryptocurrency from the user after the completion of the operation, without being sure that he had enough money. This approach is acceptable only for an internal pilot and, of course, adds problems when designing a full-fledged production project.
To all of the above, the dampness of the platform itself is added. For example, if you write a smart contract with logic other than ERC-20 tokens, you will run into an error handling problem. Usually, with incorrect input or incorrect operation of our methods, we receive an error code in response. In the case of Ethereum, we cannot get anything other than the amount of gas spent to perform this function. Gas is the currency that you have to pay for transactions and calculations: the more operations in your code, the more you will pay. So to understand why the code doesn't work, you first test it by simulating all possible errors and hardcode the gas used as the 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 exist, they do not provide interfaces for signing external transactions. This means that you will not see a native application if it does not have a built-in crypto-wallet, 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 private Ethereum network, and the wallet was cloud-based. But despite this, our users experienced 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 the sleeve: Self-Sovereign Identity
It is impossible to build a completely decentralized system without decentralized identity. Self-Sovereign Identity (SSI) is responsible for this part, the essence of which is that you throw out the centralized identity provider (IDP) and distribute all the data and responsibility for it to the people. Now the user himself decides what data he needs and with whom he will share it. All this information is located on the user's device. But for the exchange, we need a decentralized system for storing cryptographic evidence. All modern implementations of the SSI concept use the blockchain as a repository.
"What's with the ace up your 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 trade unions. In Germany, companies are prohibited from monitoring the movements of employees, and trade unions control this. These restrictions put an end to the centralized storage of user identity data, since in this case we would know the location of employees. At the same time, we could not help but check them because of the possibility of stealing scooters. But thanks to Self-Sovereign Identity, our users used the system anonymously, and the scooter itself checked with them before the start of the rental. As a result, we kept impersonal user metrics, we didn’t have any documents or personal data: they were all contained 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 ourselves, as this requires expertise in cryptography and a lot of time. Instead, we took the product of our partners Jolocom and integrated their mobile wallet and services into our platform. Unfortunately, this product has one significant disadvantage: the main development language is Node.js.
Such a technological stack greatly limits us in the choice of hardware built into the scooter. Fortunately, at the very beginning of the project, our choice fell on the Raspberry Pi Zero, and we took advantage of all the advantages of a full-fledged microcomputer. This allowed us to run bulky Node.js on a scooter. In addition, we received monitoring and remote access via vpn using ready-made tools.
In conclusion
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 when designing the architecture that did not allow us to make the service completely decentralized, but even without these mistakes, we would hardly have been able to create a serverless platform. It's one thing to write another crypto-pyramid, and quite another - a full-fledged service in which you need to handle errors, solve border cases and perform pending tasks. Let's hope that the new platforms that have appeared recently will be more flexible and functional.
Source: habr.com