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 toujours 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 puisque nous avions un scooter du sponsor de ce hackathon. Le prototype ressemblait à une application mobile permettant de démarrer un scooter via NFC. D’un point de vue marketing, l’idée était soutenue par l’histoire d’un « avenir radieux » avec un écosystème ouvert où n’importe qui peut devenir locataire ou propriétaire, le tout sur la base de contrats intelligents.
Nos parties prenantes ont vraiment aimé cette idée et ont décidé d'en faire un prototype à exposer lors d'expositions. Après plusieurs démonstrations réussies au Mobile World Congress et à Bosch Connected World en 2019, il a été décidé de tester la location de scooters auprès de vrais utilisateurs, les employés de Deutsche Telekom. Nous avons donc commencé à développer un MVP à part entière.
Blockchain sur des béquilles
Je ne pense pas qu'il soit utile d'expliquer quelle est la différence entre un projet destiné à être montré sur scène et un projet destiné à être utilisé par de vraies personnes. En six mois, nous avons dû transformer le prototype brut en quelque chose de convenable pour un pilote. Et puis nous avons compris 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é à créer 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 effectuer d'actions en attente ou planifiées. Dans notre projet, cela ne nous a pas permis de mettre en place un service de location à la minute, comme le font la plupart des services d'autopartage modernes. Par conséquent, nous avons débité la cryptomonnaie de l’utilisateur après avoir terminé la transaction, sans être sûr qu’il disposait de suffisamment d’argent. Cette approche n'est acceptable que pour un pilote interne et, bien entendu, ajoute des problèmes lors de la conception d'un projet de production à part entière.
À tout cela s’ajoute l’humidité de la plate-forme elle-même. Par exemple, si vous rédigez un contrat intelligent avec une logique différente des jetons ERC-20, vous rencontrerez des problèmes de gestion des erreurs. Habituellement, si la saisie est incorrecte ou si nos méthodes ne fonctionnent pas correctement, nous recevons un code d'erreur en réponse. Dans le cas d’Ethereum, nous ne pouvons obtenir autre chose que la quantité de gaz dépensée pour remplir cette fonction. Le gaz est une monnaie qui doit être payée pour les transactions et les calculs : plus il y a d'opérations dans votre code, plus vous paierez cher. Donc, pour comprendre pourquoi le code ne fonctionne pas, vous le testez d'abord en simulant toutes les erreurs possibles et codez en dur le gaz dépensé 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 honnêtement une application mobile qui fonctionne avec la blockchain, 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 que vous ne verrez pas une application native à moins qu’elle ne dispose d’un portefeuille crypto intégré, en lequel les utilisateurs auront peu confiance (je ne lui ferais pas confiance). En conséquence, nous avons également dû prendre des raccourcis ici. Les contrats intelligents ont été livrés au réseau privé Ethereum et le portefeuille était basé sur le cloud. Mais malgré cela, nos utilisateurs ont connu tous les « délices » des services décentralisés sous la forme de longues attentes pour les 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.
Un atout dans le trou : l'identité auto-souveraine
Vous ne pouvez pas construire un système complètement décentralisé sans identité décentralisée. L'identité auto-souveraine (SSI) est responsable de cette partie, dont l'essence est que vous supprimez le fournisseur d'identité centralisé (IDP) et distribuez toutes les données et la responsabilité de celles-ci aux personnes. L'utilisateur décide désormais 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 l’échange, nous aurons besoin d’un système décentralisé de stockage des preuves cryptographiques. Toutes les implémentations modernes du concept SSI utilisent la blockchain comme stockage.
"Qu'est-ce que cela a à voir avec l'as dans le trou ?" - tu demandes. Nous avons lancé le service de tests internes sur nos propres collaborateurs à Berlin et Bonn et nous avons rencontré des difficultés du fait des syndicats allemands. En Allemagne, il est interdit aux entreprises de surveiller les mouvements des salariés, et les syndicats contrôlent cette surveillance. Ces restrictions mettent fin au stockage centralisé des données d’identité des utilisateurs, puisque dans ce cas on connaîtrait la localisation des employés. En même temps, nous ne pouvions pas nous empêcher de les contrôler en raison de la possibilité de vols de scooters. Mais grâce à l’identité auto-souveraine, nos utilisateurs ont utilisé le système de manière anonyme et le scooter lui-même a vérifié leur permis de conduire avant de commencer la location. En conséquence, nous avons stocké des métriques d'utilisateurs anonymes ; nous n'avions aucun document ni donnée personnelle : ils étaient tous contenus 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 m'a posé des problèmes
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 profité du produit de notre partenaire Jolocom et avons 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.
Cette pile technologique limite considérablement notre choix de matériel intégré à un scooter. Heureusement, au tout début du projet, nous avons choisi le Raspberry Pi Zero, et nous avons profité de tous les avantages d'un micro-ordinateur à part entière. Cela nous a permis d'exécuter des Node.js volumineux sur le scooter. De plus, nous avons bénéficié d'une surveillance et d'un accès à distance via VPN à l'aide d'outils prêts à l'emploi.
En conclusion
Malgré toutes les « douleurs » et les problèmes, le projet a été lancé. Tout n'a pas fonctionné comme prévu, mais il était vraiment possible de conduire des scooters en les louant.
Oui, nous avons commis un certain nombre d'erreurs lors de la conception de l'architecture qui ne nous ont pas permis de rendre le service complètement décentralisé, mais même sans ces erreurs, nous aurions difficilement pu créer une plateforme sans serveur. C'est une chose d'écrire une autre crypto-pyramide, et une autre d'écrire un service à part entière dans lequel vous devez gérer les erreurs, résoudre les cas limites et effectuer les tâches en attente. Espérons que les nouvelles plateformes apparues récemment seront plus flexibles et fonctionnelles.
Source: habr.com