Plan de migration

Concernant ce plan de migration que je découvre aujourd’hui, je suis personnellement incapable de suivre l’approche consistant à d’abord tout théoriser, et ce n’est pas de cette manière que l’on procède dans mon boulot UNL (je travaille pour une crypto utilisant substrate).

Ce que je propose, c’est de continuer ma PoC à mon rythme, avec les contributeurs qui veulent bien m’y aider, et au fur et à mesure que l’on avance dans cette PoC, ça permettra de confirmer ou infirmer ce qu’il est possible d’implémenter, et de voir comment implémenter au plus simple.

Je suis d’accord pour discuter en parallèle du nouveau protocole, mais je n’aurais pas le temps de participer à tous les échanges, ni de répondre à tous les questionnements qui suivront mes avis, car je préfère consacrer le peu de temps libre que je peux dégager pour la Ğ1 à coder.

Aussi, quelques échanges vocaux vont bien plus vite que de long échanges écris, je préfère donc faire une visio de temps en temps plutôt que de participer à des interminables débat écris.


Voici un plan de migration approximatif que j’ai en tête à l’instant t en ce 10 janvier 2022, il peut changer totalement dans les semaines et mois à venir, en fonction de nos échanges et de l’expérience apportée par la PoC:

  1. Remplacer AURA par BABE
  2. Développer la sous-toile forgeron
  3. Développer la logique offchain qui vérifie la règle de distance, avec système similaire à une sorte d’oracle pour l’injection onchain du résultat
  4. Benchmarker les « poids » de tout les extrinsics
  5. Créer une chain spec pour une 1ère monnaie Ğtest substrate sans migration
  6. Développer l’écosystème autour de cette monnaie de test (clients, indexers, systèmes de stockages de données utilisateur).
  7. Coder un outil permettant de convertir un state Duniter v1 en chain spec pour duniter v2.
  8. Migrer la Ğtest
  9. tester intensivement la Ğtest migrée, vérifier que tout à bien été migré
  10. Faire une migration à blanc de la Ğ1 (une sorte de fork de la Ğ1 qui sera supprimée après quelques semaines ou mois de tests)
  11. Refaire des migrations à blanc si besoin, jusqu’à ce que l’on soit suffisamment confiant pour réaliser la vraie migration.
  12. Migrer la Ğ1

Volontairement je ne détaille pas, certains points nécessitent de longues explications que je ferai plus tard quand je trouverai le temps (peut-être seulement en visio si trop long à l’écrit).
Je n’ai pas inclus dans ce plan toute la partie communication avec les utilisateurs, qui sera essentielle à bien préparer en amont, mais ça ne sert à rien de communiquer trop tôt, je pense pas avant l’étape 8 ou 9.
Je n’ai également pas parlé de toute la partie « coder des tests automatisés », il faudra évidemment couvrir le code de tests automatisés le plus possible, c’est un travail long et chiant mais indispensable pour avoir quelque chose qui tienne la route.

Ne me demandez pas de dates, je n’en sais rien moi-même, ça dépendra de combien on sera, du temps que chacun pourra y consacrer, et de l’ampleur des problèmes techniques que l’on rencontrera.

J’aurais probablement de nouvelles absences plus ou moins longue, mais j’espère qu’avec ou sans moi cette migration finira par advenir !

6 Likes