Get best of the week

Développer un logiciel de location décentralisée de scooters. Qui a dit que ce serait facile?

Dans cet article, je parlerai de la façon dont nous avons essayé de construire une location de scooter décentralisée sur des contrats intelligents et pourquoi nous avions encore besoin d'un service centralisé.



Comment tout a commencé


En novembre 2018, nous avons participé à un hackathon dédié à l'Internet des objets et à la blockchain. Notre équipe a choisi le partage de scooter comme idée, car nous avions un scooter du sponsor de ce hackathon. Le prototype ressemblait à une application mobile qui vous permet de faire fonctionner un scooter via NFC. D'un point de vue marketing, l'idée a été renforcée par une histoire d'un «avenir radieux» avec un écosystème ouvert où chacun peut devenir locataire ou propriétaire, le tout basé sur des contrats intelligents.

Nos parties prenantes ont beaucoup aimé cette idée et ont décidé de la transformer en prototype de démonstration lors d'expositions. Après plusieurs expositions réussies au Mobile World Congress et à Bosch Connected World en 2019, il a été décidé de tester la location de scooters sur de vrais utilisateurs, employés de Deutsche Telekom. Nous avons donc commencé à développer un MVP à part entière.

Chaîne Blockchain


Je pense que cela ne vaut pas la peine d'expliquer quelle est la différence entre un projet à montrer sur scène et celui que de vraies personnes utiliseront. Pendant six mois, nous avons dû transformer le prototype brut en quelque chose de convenable pour le pilote. Et puis nous avons réalisé ce que signifie «douleur».

Afin de rendre notre système décentralisé et ouvert, nous avons décidé d'utiliser les contrats intelligents Ethereum. Le choix s'est porté sur 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 mettre en œuvre notre projet comme suit.



Mais, malheureusement, un contrat intelligent est un code exécuté par une machine virtuelle au moment d'une transaction, et il ne peut pas remplacer un serveur à part entière. Par exemple, un contrat intelligent ne peut pas exécuter des activités en attente ou planifiées. Dans notre projet, cela ne nous a pas permis de mettre en place le service de location à la minute, comme le font la plupart des voitures modernes. Par conséquent, nous avons déduit la crypto-monnaie de l'utilisateur après la fin de l'opération sans la certitude qu'il a suffisamment d'argent. Cette approche n'est acceptable que pour le pilote interne et, bien sûr, ajoute aux problèmes lors de la conception d'un projet de production à part entière.

À tout ce qui précède, l'humidité de la plate-forme elle-même est ajoutée. Par exemple, en écrivant un contrat intelligent avec une logique autre que des jetons ERC-20, vous rencontrerez le problème de la gestion des erreurs. Habituellement, avec une entrée incorrecte ou un fonctionnement incorrect de nos méthodes, nous obtenons un code d'erreur en réponse. Dans le cas d'Ethereum, nous ne pouvons obtenir que la quantité de gaz dépensée pour remplir cette fonction. Le gaz est la devise dont vous avez besoin pour payer les transactions et les calculs: plus il y a de transactions dans votre code, plus vous payez. Par conséquent, pour comprendre pourquoi le code ne fonctionne pas, vous devez d'abord le tester, simuler toutes les erreurs possibles et coder en dur le gaz usé comme code d'erreur. Mais si vous modifiez votre code, cette gestion des erreurs sera interrompue.

De plus, il est presque impossible de créer une application mobile qui fonctionne honnêtement avec la blockchain, sans utiliser une clé stockée quelque part dans le cloud. Bien que les portefeuilles honnêtes existent, ils ne fournissent pas d'interfaces pour signer des transactions externes. Cela signifie que vous ne verrez pas l'application native si elle n'a pas de portefeuille crypté intégré, auquel les utilisateurs auront peu confiance (je ne ferais pas confiance). En conséquence, ici, nous avons également dû couper un coin. Des contrats intelligents ont été livrés au réseau privé Ethereum et le portefeuille était nuageux. Mais malgré cela, nos utilisateurs ont ressenti tous les «charmes» des services décentralisés sous la forme d'une longue attente de transactions plusieurs fois par session de location.

Tout cela nous amène à cette architecture. D'accord, c'est très différent de ce que nous avions prévu.



Ace dans votre manche: identité auto-souveraine


Vous ne pouvez pas construire un système entièrement décentralisé sans identification décentralisée. L'identité auto-souveraine (SSI) est responsable de cette partie, dont l'essence est que vous jetez un fournisseur d'identité centralisé (IDP) et distribuez aux gens toutes les données et leur responsabilité. L'utilisateur décide maintenant des données dont il a besoin et avec qui il les partagera. Toutes ces informations se trouvent sur l'appareil de l'utilisateur. Mais pour le partage, nous avons besoin d'un système de stockage décentralisé des preuves cryptographiques. Toutes les implémentations modernes du concept SSI utilisent la blockchain comme stockage.

"Qu'est-ce que l'as dans ma manche?" - tu demandes. 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, il est interdit aux entreprises de surveiller les mouvements des employés, et les syndicats contrôlent cela. Ces restrictions ont mis fin au stockage centralisé des données d'identité des utilisateurs, car dans ce cas, nous aurions connu l'emplacement des employés. Dans le même temps, nous n'avons pas pu les vérifier en raison de la possibilité de détourner des scooters. Mais grâce à l'auto-identité souveraine, nos utilisateurs ont utilisé le système de manière anonyme, et le scooter lui-même a vérifié la disponibilité d'un permis de conduire avant de commencer la location. En conséquence, nous avons conservé des statistiques d'utilisateurs anonymes, nous n'avions aucun document ni aucune donnée personnelle: elles étaient toutes stockées sur les appareils des conducteurs eux-mêmes.Ainsi, grâce à SSI, la solution au problème de notre projet était prête avant même son apparition.

L'appareil a provoqué des problèmes


Nous n'avons pas implémenté l'auto-identité souveraine, car cela nécessite une expertise en cryptographie et beaucoup de temps. Au lieu de cela, nous avons profité du 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 principal langage de développement est Node.js.

Une telle pile technologique nous limite beaucoup dans le choix du fer intégré dans un scooter. Heureusement, au tout début du projet, notre choix s'est porté sur le Raspberry Pi Zero, et nous avons profité du micro-ordinateur à part entière. Cela nous a permis d'exécuter le Node.js encombrant sur un scooter. De plus, nous avons obtenu la surveillance et l'accès à distance via vpn en utilisant des outils prêts à l'emploi.

finalement


Malgré toute la «douleur» et les problèmes, le projet a été lancé. Tout n'a pas fonctionné comme prévu, mais il était vraiment possible de monter des scooters en les louant.

Oui, nous avons commis un certain nombre d'erreurs dans la conception de l'architecture, ce qui ne nous a pas permis de décentraliser complètement le service, mais même sans ces erreurs, nous n'aurions guère réussi à créer une plateforme sans serveur. C'est une chose d'écrire une autre crypto-pyramide et une autre est un service à part entière dans lequel vous devez gérer les erreurs, résoudre les cas de frontière et effectuer des tâches en attente. Espérons que les nouvelles plates-formes récemment apparues seront plus flexibles et fonctionnelles.

More articles:


All Articles