Développer un logiciel pour un service de scooters en libre-service décentralisé. Qui a dit que ce serait facile ?

Dans cet article, je vais expliquer comment nous avons tenté de construire un service de location de scooters décentralisé basé sur des contrats intelligents et pourquoi nous avons malgré tout eu besoin d'un service centralisé.

Comment tout a commencé

En novembre 2018, nous avons participé à un hackathon consacré à l'Internet des objets et à la blockchain. Notre équipe a choisi l'idée du scooter-sharing, car nous avions un scooter fourni par le sponsor de cet hackathon. Le prototype était une application mobile permettant de démarrer le scooter via NFC. Du point de vue marketing, l'idée était soutenue par le récit d'un « avenir radieux » avec un écosystème ouvert où chacun peut être locataire ou prêteur, le tout basé sur des contrats intelligents.

Cette idée a beaucoup plu à nos parties prenantes, qui ont décidé de la transformer en prototype pour des démonstrations lors d'expositions. Après plusieurs présentations réussies au Mobile World Congress et au Bosch Connected World en 2019, il a été décidé de tester la location de scooters auprès d'utilisateurs réels, des employés de Deutsche Telekom. Ainsi, nous avons commencé à développer un MVP complet.

La blockchain sur des béquilles

Je pense qu'il n'est pas nécessaire d'expliquer la différence entre un projet de démonstration sur scène et un projet destiné à être utilisé par de vraies personnes. En six mois, nous devions transformer un prototype brut en quelque chose qui convienne pour un pilote. C'est alors que nous avons compris ce que signifie le terme “douleur”.

Pour rendre notre système décentralisé et ouvert, nous avons décidé d'utiliser des contrats intelligents Ethereum. Nous avons choisi cette plateforme de services en ligne décentralisés en raison de sa popularité et de sa capacité à construire une application sans serveur. Nous avions prévu de réaliser notre projet de la manière suivante.

Mais, malheureusement, un contrat intelligent est un code exécuté par une machine virtuelle au moment de la transaction, et il ne peut pas remplacer un système complet. serveurPar exemple, un contrat intelligent ne peut pas effectuer d'actions différées ou programmées. Dans notre projet, cela n'a pas permis de mettre en place un service de location à la minute, comme le font la plupart des services de covoiturage modernes. Par conséquent, nous débitons la cryptomonnaie de l'utilisateur après la fin de l'opération sans être certains qu'il dispose d'un montant suffisant. Cette approche est acceptable uniquement pour un pilote interne et, sans aucun doute, complique la conception d'un véritable projet en production.

À cela s’ajoute l’humidité de la plateforme elle-même. Par exemple, si vous écrivez un contrat intelligent avec une logique différente de celle des tokens ERC-20, vous serez confronté à des problèmes de gestion des erreurs. En général, lorsque nous avons des entrées incorrectes ou que nos méthodes fonctionnent mal, nous recevons un code d'erreur en réponse. Dans le cas d'Ethereum, nous ne pouvons obtenir rien d'autre que la quantité de gaz dépensée pour exécuter cette fonction. Le gaz est la monnaie qu'il faut payer pour les transactions et les calculs : plus vous avez d'opérations dans votre code, plus vous paierez. Ainsi, pour comprendre pourquoi le code ne fonctionne pas, vous devez d'abord le tester en simulant toutes les erreurs possibles, et coder en dur le gaz dépensé comme code d'erreur. Mais si vous modifiez votre code, ce traitement des erreurs sera cassé.

De plus, il est pratiquement impossible de créer une application mobile qui fonctionne avec la blockchain de manière honnête, sans utiliser une clé stockée quelque part dans le cloud. Bien que des portefeuilles honnêtes existent, ils ne fournissent pas d'interfaces pour signer des transactions externes. Cela signifie qu'aucune application native ne sera disponible à moins qu'elle n'intègre un portefeuille crypto, auquel les utilisateurs auront peu confiance (moi, je ne ferais pas confiance). En conséquence, ici aussi, nous avons dû couper les coins ronds. Les contrats intelligents étaient livrés sur un réseau privé Ethereum, et le portefeuille était dans le cloud. Mais malgré cela, nos utilisateurs ont ressenti toutes les "joies" des services décentralisés sous la forme d'attentes prolongées pour des transactions plusieurs fois par session de location.

Tout cela nous amène à une architecture comme celle-ci. Convenez qu'elle diffère fortement de ce que nous avions prévu.

Atout dans la manche : Identité auto-souveraine

Il est impossible de construire un système complètement décentralisé sans une identification décentralisée. C'est cette partie qui est gérée par l'Identité Auto-Souveraine (SSI), dont l'essence réside dans le fait que vous éliminez le fournisseur d'identité centralisé (IDP) et que vous remettez au peuple toutes les données et la responsabilité qui en découle. Désormais, l'utilisateur décide lui-même des données dont il a besoin et avec qui il veut les partager. Toutes ces informations résident sur l'appareil de l'utilisateur. Mais pour un échange, nous aurons besoin d'un système décentralisé de stockage de preuves cryptographiques. Toutes les implémentations modernes du concept de SSI utilisent la blockchain comme stockage.

« Quel rapport avec un atout dans la manche ? » vous demanderez-vous. Nous avons lancé le service pour un test interne sur nos propres employés à Berlin et à Bonn, et nous avons rencontré des difficultés face aux syndicats allemands. En Allemagne, les entreprises ne sont pas autorisées à suivre les déplacements des employés, et les syndicats contrôlent cela. Ces restrictions mettent un terme au stockage centralisé des données d'identification des utilisateurs, car dans ce cas, nous saurions où se trouvent les employés. En même temps, nous ne pouvions pas ne pas les vérifier en raison du risque de vol des scooters. Mais grâce à l'Identité Auto-Souveraine, nos utilisateurs utilisaient le système de manière anonyme, et le scooter vérifiait la validité du permis de conduire avant le début de la location. En conséquence, nous avions des métriques anonymisées des utilisateurs, sans documents ni données personnelles : toutes celles-ci étaient contenues sur les appareils des chauffeurs eux-mêmes. Ainsi, grâce à la SSI, la solution à ce problème dans notre projet était prête avant même son apparition.

L'appareil a posé problème

Nous n'avons pas mis en œuvre nous-mêmes l'Identité Auto-Souveraine, car cela nécessite une expertise en cryptographie et beaucoup de temps. Au lieu de cela, nous avons utilisé le produit de nos partenaires Jolocom et intégré leur portefeuille mobile et leurs services dans notre plateforme. Malheureusement, ce produit présente un inconvénient majeur : le langage de développement principal est Node.js.

Cette pile technologique nous limite considérablement dans le choix du matériel intégré au scooter. Heureusement, dès le début du projet, nous avons opté pour le Raspberry Pi Zero, ce qui nous a permis de bénéficier de tous les avantages d'un véritable micro-ordinateur. Cela nous a permis de faire fonctionner Node.js sur le scooter. De plus, nous avons obtenu un monitoring et un accès à distance via vpn, en utilisant des outils prêts à l'emploi.

En conclusion

Malgré toutes les "difficultés" et les problèmes, le projet a été lancé. Tout ne fonctionnait pas comme nous l'avions prévu, mais il était en effet possible de faire des balades en louant les scooters.

Oui, nous avons commis plusieurs erreurs lors de la conception de l'architecture, qui ne nous ont pas permis de rendre le service entièrement décentralisé, mais même sans ces erreurs, il aurait été difficile de créer une plateforme serverless. Écrire une énième pyramide crypto est une chose, créer un véritable service qui doit gérer les erreurs, résoudre des cas extrêmes et exécuter des tâches différées en est une autre. Espérons que les nouvelles plateformes qui ont récemment vu le jour seront plus flexibles et fonctionnelles.

Source : habr.com