In this article, I will discuss how we attempted to build a decentralized scooter rental system on smart contracts and why we still needed a centralized service.
How It All Started
In November 2018, we participated in a hackathon focused on the Internet of Things and blockchain. Our team chose scooter sharing as our idea since we had a scooter from the hackathon sponsor. The prototype resembled a mobile application allowing users to start a scooter via NFC. From a marketing perspective, the idea was supported by a narrative of a 'bright future' with an open ecosystem where anyone could be a renter or a lessor, all based on smart contracts.
This idea was very well received by our stakeholders, and they decided to turn it into a prototype for demonstration at exhibitions. After several successful showcases at Mobile World Congress and Bosch Connected World in 2019, a decision was made to test the scooter rental with real users, employees of Deutsche Telekom. Thus, we began developing a full-fledged MVP.
Blockchain on crutches
I think it is unnecessary to explain the difference between a project meant for stage presentation and one that real people will use. We had six months to transform a raw prototype into something suitable for a pilot. And then we understood what 'pain' truly meant.
To make our system decentralized and open, we decided to use Ethereum smart contracts. This decentralized online service platform was chosen due to its popularity and the ability to build a serverless application. We planned to implement our project as follows.
Unfortunately, a smart contract is code executed by a virtual machine at the moment of a transaction, and it cannot replace a full-fledged server. For example, a smart contract cannot perform delayed or scheduled actions. In our project, this prevented us from implementing a per-minute rental service as many modern car-sharing services do. Consequently, we deducted cryptocurrency from the user after the operation was completed, without being certain that they had sufficient funds. This approach is only acceptable for an internal pilot and certainly adds complications when designing a full production project.
In addition to all of the above, there is the dampness of the platform itself. For instance, if you write a smart contract with logic different from ERC-20 tokens, you will encounter issues with error handling. Usually, when there is incorrect input or our methods do not work properly, we receive an error code in response. In the case of Ethereum, we can obtain nothing but the amount of gas consumed to execute that function. Gas is the currency that must be paid for transactions and computations: the more operations in your code, the more you will pay. Therefore, to understand why the code does not work, you first test it by simulating all possible errors and hardcoding the spent gas as the error code. However, if you change your code, this error handling will break.
Moreover, it is nearly impossible to create a mobile application that interacts with the blockchain honestly without using a key stored somewhere in the cloud. While honest wallets do exist, they do not provide interfaces for signing external transactions. This means that a native application will be out of reach unless it has an integrated crypto wallet, which users are likely to trust little (I certainly wouldn’t). As a result, we also had to cut corners here. Smart contracts were delivered to a private Ethereum network, while the wallet was cloud-based. Nevertheless, our users experienced all the "delights" of decentralized services with long waits for transactions several times during the rental session.
All this brings us to this architecture. Agree, it is vastly different from what we originally planned.
A Ace in the Hole: Self-Sovereign Identity
You cannot build a fully decentralized system without decentralized identity. This part is handled by Self-Sovereign Identity (SSI), which essentially means discarding a centralized identity provider (IDP) and giving people all the data and responsibility for it. Now, the user decides what data they need and who they will share it with. All this information resides on the user's device. However, for sharing, we will need a decentralized system for storing cryptographic proofs. All modern implementations of the SSI concept use blockchain as storage.
"What does the ace up the sleeve have to do with it?" you might ask. We launched the service for an internal test with our own employees in Berlin and Bonn, and we faced difficulties in the form of German labor unions. In Germany, companies are prohibited from tracking employee movements, and unions monitor this. These restrictions rule out centralized storage of user credential data, as we would then know the locations of employees. At the same time, we could not avoid checking them due to the possibility of scooter thefts. However, thanks to Self-Sovereign Identity, our users used the system anonymously, and the scooter checked the driver's license before starting the rental. As a result, we stored anonymized user metrics, and we had no documents or personal data: all of it was kept on the drivers' devices. Thus, thanks to SSI, the solution to the problem in our project was ready even before it arose.
The device threw us a problem.
We did not implement Self-Sovereign Identity ourselves, as this requires expertise in cryptography and a lot of time. Instead, we used the product of our partners at Jolocom and integrated their mobile wallet and services into our platform. Unfortunately, this product has one significant drawback: the primary development language is Node.js.
This technology stack greatly limits our choice of hardware embedded in the scooter. Fortunately, at the very start of the project, we opted for the Raspberry Pi Zero and took advantage of all the benefits of a full-fledged microcomputer. This allowed us to run bulky Node.js on the scooter. In addition, we gained monitoring and remote access through vpn, using available tools.
In conclusion
Despite all the "pain" and problems, the project was launched. Not everything worked as we planned, but it was indeed possible to ride the scooters by renting them.
Yes, we made a number of mistakes in designing the architecture that prevented us from making the service fully decentralized, but even without these mistakes, it would have been unlikely for us to create a serverless platform. It's one thing to write another crypto pyramid and quite another to create a full-fledged service where you need to handle errors, address edge cases, and execute deferred tasks. Let's hope that the new platforms that have emerged recently will be more flexible and functional.
Source: habr.com
