Concevoir une blockchain en un été

Parfois, on a des idées à la con.

Essayer de coder une blockchain de zéro en est sûrement une.

Seulement, c’est ce que j’ai passé l’été à faire, donc autant tout documenter ici.

Pavé César, ceux qui n’ont pas lu te saluent : voici Muffin Network.

Une blockchain Proof-of-Stake qui n’est pas stupide et dont le développement a débuté en mai 2022.

Pourquoi

Il existe des dizaines de blockchains différentes. Certaines sont spécialisées dans l’infrastructure, d’autres dans le scaling, mais aucune n’est vraiment agréable à utiliser, que ce soit par les utilisateurs comme par les développeurs.

Elles manquent de simplicité et d’intuitivité.

Apporter de la simplicité à une solution technologique nouvelle et complexe n’est pas une chose facile, mais il s’agit de ce vers quoi doit tendre toute innovation.

Dès le départ, le but de Muffin était de proposer une solution simple à utiliser, et sur laquelle il est simple de développer des applications.

Pour cela, il fallait apporter ce qui fera la différence pour les utilisateurs et les développeurs.

L’utilisateur final n’en a rien à faire de comment le moteur fonctionne sous le capot, il veut une voiture qui avance.

Un utilisateur de blockchain doit pouvoir effectuer des transactions facilement, ainsi que gérer son identité virtuelle. Il n’a pas besoin de connaître les détails, il veut que ça marche.

Un développeur veut pouvoir développer et déployer ses applications rapidement et facilement. Lui non plus n’a pas forcément besoin de connaître tous les détails. Il lui faut juste savoir comment va s’exécuter son application et dans quelles limites. Pour le reste, il faut lui faciliter le travail au maximum.

Pour ces raisons, Muffin ne devait pas simplement être une blockchain, mais une solution complète centrée autour d’une blockchain

Tous les choix de conception de Muffin devaient donc découler de ces principes.

Fonctionnement

Système économique

La première étape de la conception consistait à choisir un système financier et économique cohérent, ce que la plupart des blockchains n’ont pas.

Bitcoin est souvent vanté pour sa réserve limitée de jetons, mais c’est en réalité une mauvaise idée.

À ce jour, la distribution de Bitcoins est toujours en cours, près de 13 après le lancement de la blockchain, mais le réseau aura rapidement un problème de liquidité s’il devient un véritable moyen de paiement.

Aussi révolutionnaire la technologie Blockchain soit-elle, elle ne peut pas pour autant se soustraire aux lois de l’inflation, de la déflation, et de la distribution de la liquidité.

En l’état, Bitcoin est parfait en tant qu’or numérique, mais ce n’est pas un système économique tenant compte des réalités.

D’autres blockchains telles qu’Ethereum comportent un système de contrôle de l’inflation et de la déflation, si tant est que l’on puisse appeler ça comme ça.

Le problème, c’est que l’émission de nouveaux jetons se fait toujours par les mineurs/validateurs. Or, les mineurs sont probablement les acteurs les moins indiqués pour distribuer ces jetons, d’autant plus dans un système Proof-of-Stake où ils pourraient être tentés de les staker.

Donc, quelle alternative à tout ça ?

Mon idée initiale était de recopier ce qui marche déjà, c’est-à-dire le système des banques centrales.

Il y avait un petit problème cependant : comment transposer le système de planche à billets des banques centrales dans un système décentralisé où personne en particulier n’a le contrôle ? Comment sanctionner un créancier malhonnête ?

Comment faire pour que les utilisateurs puissent emprunter de l’argent à la blockchain elle-même ? Que faire en cas de défaut de paiement ?

Il est évident que toutes ces questions ont une réponse, mais le morceau était trop gros pour une première approche.

J’ai donc décidé d’explorer des systèmes alternatifs, mais toujours ancrés dans notre réalité économique.

Il était tout à fait possible d’utiliser une planche à billets, le problème était la distribution.

S’il n’était pas possible de distribuer des nouveau jetons en échange d’une créance, il était tout à fait possible de les distribuer à tout le monde, lors d’évenements définis, en même temps sans contrepartie.

Si on ne peut pas financer l’investissement, on peut toujours financer la consommation.

Mieux que la planche à billets : l’hélicoptère monétaire.

Le but était donc devenu d’avoir assez de liquidité pour tous les utilisateurs uniques du réseau.

Voulant déjà implémenter une gestion de l’identité au sein de Muffin, l’idée était toute trouvée.

La masse monétaire serait indexée sur le nombre de « Muffin ID », et à chaque fois qu’un nouvel ID serait créé, un certain nombre de Floats (la cryptomonnaie officielle de Muffin) seraient distribués de manière égale entre tous les possesseurs d’IDs.

Choix technologiques

Muffin n’est pas la blockchain la plus élaborée, ni la plus optimisée.

Bitcoin et Ethereum reposent sur des concepts mathématiques et d’informatique théorique que je ne maîtrise pas.

Je suis donc allé au plus simple, avec les technos que je connais et ce qui a déjà fait ses preuves.

Muffin est écrite en Typescript, est exécutée avec Node JS, et utilise Level comme base de donnée.

Certes, Ethereum est écrite en Go, et Go est bien plus rapide, mais Typescript reste à mon sens le langage le plus lisible et avec lequel il est le plus facile de concevoir en partant de zéro.

Même si les deux blockchains ne partagent pas le même langage, Muffin hérite tout de même de quelques concepts d’Ethereum :

  • Le système clé/adresse est le même. Votre clé privée d’Ethereum vous permettra d’utiliser la même adresse sur Muffin.
  • Une API RPC à peu près fonctionnelle permettant une certaine compatibilité avec les portefeuilles EVM-compatible tels que Metamask
  • Un système de hashage similaire. Une transaction comportant les mêmes données aura le même hash sur Ethereum et sur Muffin.

En revanche, Muffin se distingue sur un certain nombre de points :

  • Une API REST (plus ou moins) CRUD
  • Le gas est remplacé par des frais calculés sur le montant de la transaction. Le gas est conçu pour motiver les validateurs, il n’a pas besoin de dépendre de l’offre et de la demande, juste d’exister.
  • Les contrats sont écrits en Javascript. Le web est écrit en Javascript, et la blockchain, c’est du web.

Les Muffin IDs

Floater homepage

Un Muffin ID, c’est une pièce d’identité stockée sur la blockchain.

L’objectif était de fournir un moyen de s’authentifier sur le web facilement de manière fiable, récupérable, tout en protégeant la vie privée des utilisateurs.

C’est avec ces idées en tête que j’ai conçue les Muffin IDs de cette façon :

  • Tous les champs sont chiffrés avec des clés différentes
  • Les différentes clés sont obtenues à partir d’une clé principale
  • La clé principale permet de modifier certains champs de l’ID et de le transférer d’une adresse vers une autre.
  • Seule la clé principale permet d’utiliser le Muffin ID. Même en cas de piratage de l’adresse qui lui est associée, l’ID n’est pas compromis.

Nights & Weekends

Buildspace Night and Weekends

En juin j’ai postulé pour faire partie de la première session du programme Nights & Weekends de Buildspace.

Ce programme, un combo de Y Combinator et de Stanford d’après son créateur, avait pour but de prendre 500 « builders » et de les accompagner pendant 6 semaines pour qu’ils lancent leur propre projet.

J’ai été accepté, comme beaucoup parce que j’avais déjà lancé des projets par le passé.

Chaque semaine pendant 6 semaines, j’ai donc dû expliquer ce sur quoi j’avais travaillé et faire une démo.

Cela peut sembler inutilement contraignant, mais le fait de devoir rendre des comptes sur mon avancée m’a permis de planifier mon travail et de me forcer à respecter les délais, et donc d’aller beaucoup plus vite.

À la fin des 6 semaines, on nous a demandé d’exposer notre projet au salon virtuel Nights & Weekends Demo Day. Je suis content d’y avoir participé, car je ne pensais honnêtement pas tenir jusqu’à la fin des 6 semaines, et surtout c’était une épreuve que je redoutais particulièrement.

À la fin du programme, nous étions environ 150 participants à recevoir notre certificat sous forme de NFT attestant que nous avions été actif pendant les 6 semaines et que nous avions exposé à Demo Day, c’est-à-dire 30% de la promotion initiale.

Pour ma part, Nights & Weekends était une expérience très enrichissante. Je recommande à quiconque souhaitant lancer un projet d’y participer.

La partie émergée de l’iceberg

Une blockchain n’est pas un outil utilisable par le grand public. Il lui faut une couche d’abstraction.

Pour Muffin, cette couche d’abstraction se divise en 2 parties :

  1. Floater, un portefeuille crypto permettant au grand public d’envoyer des transactions et de créer un Muffin ID
  2. DevsHub, une plateforme hébergeant de la documentation et des outils pour les développeurs.

Floater prend la forme d’une application web, pensée pour le mobile, intuitive visant à faciliter le transfert d’argent entre les utilisateurs de Muffin ainsi que la gestion de leur Muffin ID.

Floater permet de :

  • Effectuer un virement d’un utilisateur vers un autre
  • Générer un QR Code de paiement contenant un destinataire et une somme due
  • Scanner un QR Code de paiement
  • Consulter l’historique des transactions
  • Créer un Muffin ID
  • Récupérer un Muffin ID associé à une autre adresse
  • Scanner des QR Codes d’authentification pour s’identifier avec un Muffin ID

Au niveau des technologies utilisées, je suis allé au plus simple en utilisant Next.js, avec la librairie graphique NextUI, encore en bêta.

Développer sur Muffin

L’un des enjeux de Muffin est de faciliter la vie aux développeurs.

C’est dans cet objectif que j’ai créé 2 modules JS :

  • muffin-utils, facilitant le développement de contrats pour Muffin
  • muffin-sdk, permettant l’implémentation de Muffin au sein de sites, applications et serveurs web

Le but de muffin-utils est de fournir des structures de contrats prêtes à l’emploi, avec le minimum de choses à écrire.

Celui de muffin-sdk est de permettre aux développeurs web d’ajouter Muffin à leurs applications le plus rapidement possible, avec leurs infrastructures existantes.

DevsHub permet également de générer des widgets d’authentification et de paiement sans avoir à écrire de code.

Pay with Muffin

Le widget Pay with Muffin peut être généré grâce à muffin-sdk et également sans code depuis DevsHub.

Il prend une adresse et un montant en paramètres, éventuellement un champ de données, et génère un QR Code pouvant être scanné depuis Floater.

Il s’agit de la manière la plus simple de se faire payer via Muffin.

Sign in with your Muffin ID

Le widget Sign in with your Muffin ID permet de s’authentifier avec un Muffin ID juste en scannant un QR Code.

Il n’est pas encore totalement sécurisé dans le sens où malgré le chiffrage des Muffin ID, il peut être assez facile de faire croire à un service peu regardant que l’on possède la bonne clé.

Marketing

Le marketing de Muffin a débuté durant Night & Weekends, puisque l’un des ateliers proposé était centré autour.

Mon utilisation théorique des différents canaux était la suivante :

  • Twitter pour faire connaître la marque, en expliquant les différents concepts de Muffin et en montrant l’avancée du projet
  • Discord pour fonder une communauté et lui permettre d’interagir (voir l’article sur Tribus)
  • Une landing page pour pouvoir rediriger vers Floater, DevsHub, et le serveur Discord

L’idée était d’attirer les utilisateurs via des distributions gratuites de Floats afin qu’ils puissent créer leur propre Muffin ID.

Ces distributions étaient annoncées sur plusieurs subreddits, mais il y a eu peu de résultats concluant de ce côté-là.

Et ensuite ?

Muffin n’est peut-être pas la solution idéale pour répondre au problème initial.

Avec le temps, elle s’est suffisamment complexifiée pour se rapprocher de ce qui se fait déjà en termes de complexité.

Peut-être que les blockchains ne sont tout simplement pas des services destinés au grand public et devraient être totalement invisibles aux yeux des utilisateurs finaux.

Peut-être aurait-il fallu centré l’expérience sur le développement et laisser les développeurs construire les outils grand-public sur cette base.

Il va donc falloir choisir entre persévérer, faire pivoter le projet, ou le ranger au placard.

Partagez cet article :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *