Nous arrivons en mars 2023, la Ğ1 va fêter ses 6 ans, et cela fait 6 mois que je suis à plein temps pour la monnaie libre. J’ai contribué à certains aspects que j’estimais les plus utiles sur le long terme :
- l’association Axiom Team, qui se met au service de la communauté, notamment pour le financement € des développements techniques
- les logiciels de l’écosystème Duniter, surtout en coordination des contributions, en documentation, et sur le cœur Duniter v2 lui-même
Aujourd’hui, j’aimerais faire un point d’étape sur la promesse de la Ğ1v2, pour voir le travail accompli et ce qu’il reste à faire avant la migration, que j’estime faisable pour le 8 mars 2025 si l’on continue à accélérer le rythme de développement.
Ğ1v2 : l’idée
L’écosystème logiciel qui fait actuellement tourner la Ǧ1 (Duniter et Cesium, mais également les pods Cesium+, silkaj, wotwizard, …) est un prototype qui a permis à la Ǧ1 d’exister, mais qui souffre de nombreux bugs et problèmes de conception que nous ne sommes pas en mesure de corriger suffisamment rapidement. Des petits chantiers sont en cours pour améliorer à la marge la vie des utilisateurs, mais rien qui permettent à la Ğ1 de “passer à l’échelle”, c’est-à-dire supporter des millions de membres.
C’est dans cette idée que Elois, qui a longtemps travaillé à améliorer Duniter v1 en y intégrant des briques Rust, a proposé en juillet 2021 de migrer la Ğ1 sur une “version 2” écrite entièrement en Rust avec le framework substrate. Cependant, après y avoir travaillé pendant plus d’un an quasiment tout seul, sans que personne ne l’aide significativement, il a décidé de ne plus développer activement, mais de se limiter à un rôle de consultant pour se préserver :
Pour éviter de me retrouver dans la même situation que lui, j’ai choisi d’utiliser mon année de chômage non pas uniquement à coder sur Duniter v2, mais également à augmenter le nombre de contributeurs et le temps qu’ils ont a consacrer.
Où en sommes-nous ?
Duniter
Côté Duniter, le logiciel fait déjà tourner une ĞDev contentant un instantané des données de la Ğ1 en date du 12 décembre 2022. Vous pouvez voir une liste des nœuds ayant activé la télémétrie et interagir avec la blockchain via l’appli pour développeurs polkadotjs app. La documentation utilisateur commence à être prête pour accueillir des nouveaux forgerons (accueil 
, accueil 
), étape indispensable à la migration (le métier de forgeron v2 nécessite plus d’assiduité que pour la v1).
Indexeur
Duniter ne serait pas grand chose sans indexeurs, qui permettent de récupérer des informations sans avoir à parcourir tous les blocs. Actuellement trois pistes sont en cours :
- duniter-indexer (+), une architecture maison mais simple. Il reste beaucoup d’événements à gérer.
- indexer subsquid, une autre piste basée sur subsquid, qui permettrait de gérer tous les événements de manière générique exhaustive, en attendant. J’explore cette piste car elle pourrait me faire gagner beaucoup de temps en phase de développement.
- hydra, une solution générique que elois avait mise en place, mais que personne n’a remis en place pour l’instant.
Ǧecko
Ğecko est le client mobile le plus abouti, il est actuellement en phase de beta-test : Devenez Testeur sur Ğecko - Outils - Support utilisateur - Forum Monnaie Libre
Il permet de réaliser la plupart des opérations grand public (création de comptes, transactions, certifications, migration de compte…).
Cesium v2
Cesium v2 gère des opérations élémentaires.
Ğcli
Ğcli est à destination des développeurs et permet déjà de réaliser plusieurs opérations sur la blockchain et de se connecter à l’indexeur.
Qu’est-ce qu’il nous reste à faire ?
Il nous reste énormément de choses à faire, voilà pourquoi je pense que ça va prendre deux ans si on continue à accélérer (et six ans si on continue au même rythme). Je vais ranger ces choses en deux catégories :
- celles indispensables si on ne veut pas que la Ğ1v2 s’arrête morte née
- celles fortement souhaitables si on veut que la Ğ1v2 soit correctement adoptée par la communauté
1. Tâches indispensables
L’avantage d’une blockchain substrate est que c’est une technologie connue. C’est aussi un inconvénient car dès que nous publierons la Ğ1v2, elle pourra être la cible d’attaques standard sur les blockchain substrate. Pour cela, il nous faut benchmarker les poids d’extrinsics. Benjamin est en train de travailler dessus grâce au financement ADEME. Mais aussi benchmarker l’accès au storage, choisir la formule de calcul des frais de transaction.
La preuve de travail de la v1 offrait de la souplesse dans la gestion des forgerons et du temps, mais le nouveau protocole de consensus utilisé dans la v2 implique d’implémenter la gestion des offences, au moins de manière basique. Sinon le réseau pourrait être fortement ralenti, ce qui aurait des conséquences sur le versement du DU (tant que #64 n’est pas implémentée).
La toile de confiance v2 n’a pour l’instant pas de critère de distance. Il faut implémenter le calcul de la règle de distance qui est une garantie pour que la toile de confiance conserve une bonne topologie.
La gdev actuellement ne tient pas en compte les certifications émises vers et venant des identités non membres (ayant perdu le statut de membre par exemple). Il faut donc implémenter un genesis pour les runtimes ĞTest et Ğ1 qui soit capable de prendre en compte ces certifications. Cela est également lié avec la gestion des identités ayant perdu le statut de membre et la disponibilité des pseudos uniques.
2. Tâches fortement souhaitables
La v2 officialise la gouvernance on-chain (alors qu’elle était implicite dans la v1) avec un comité technique. Il faut quand même choisir ce que peut faire le comité technique (par exemple les runtime upgrade), sinon il sera capable de tout faire (y compris émettre une certification pour quelqu’un d’autre par exemple). Ce n’est pas gênant si on a confiance dans le comité technique (il ne le fera pas), mais ça ne correspond absolument pas à l’idée que l’on se fait de la gouvernance sur blockchain, et donc il vaudrait mieux changer ça avant de migrer la Ğ1.
Pour ne pas avancer à l’aveugle et avoir des moyens de débugger la Ğ1v2, il faudrait augmenter la couverture de tests (unitaires, intégration, end2end) ainsi que implémenter des sanity tests. Dans le cas contraire, on pourrait se retrouver avec un gros bug bloquant sans avoir les outils nécessaires pour réparer.
La v2 apporte plusieurs notions totalement étrangères aux utilisateurs v1 notamment :
- la taxe de création de compte
- les frais de transaction
- la trésorerie commune (lié aux précédents)
- le dépôt existentiel (ça existe déjà en v1 mais ce sera probablement plus visible en v2)
- la limite stricte d’émission de certifications tous les 5 jours
- le comité technique
- le mnemonic (côté client)
Il faut vulgariser ces concepts auprès de la communauté et s’assurer de la bonne réception, sinon on risquera de casser la confiance de communauté, et ce serait très grave.
Conclusion
Je le répète encore une fois, je pense qu’on peut y arriver en deux ans si on continue à accélérer les développements. Cela implique d’y passer plus que quelques heures bénévoles par-ci par-là, et les financement € aident à avoir des personnes à plein temps. Bien sûr travailler sur la v2 n’empêche pas du tout de travailler sur la v1, comme on le voit avec le nouveau client Ğ1nkgo (cf Presentation and new light web client Ğ1nkgo).
