Traité : est défini dans le fichier de conf de chaque monnaie (gdev.json, gtest.json).
Je considère que c’est fait, au sens où il n’y a – pour l’instant – aucune monnaie à transférer vers la Trésorerie selon moi. Si cela devait toutefois changer, il suffirait d’adapter la fonction gen_genesis_data.
N’est plus nécessaire : les comptes Ğ1v1 sont importées bruts (clé publique Ed25519) car Substrate ne fait qu’extraire les clés publiques et ne contrôle pas les adresses pour le Genesis.
Fait, on voit que ce n’est pas le cas. Reste à voir d’où provient ce delta.
La conversion se fait côté Substrate, et un test couvre ce cas de figure.
Les seules sorties qui méritent encore de l’attention selon moi sont :
⚠️ Pseudo1 → Llorens cert expired between export and start
⚠️ Pseudo2 has received only 1 certs, disabling it
Je vais voir pour les déplacer côté Duniter.
OK.
Par conséquent, reste à faire :
Ne pas filtrer les certifications ou identités côté py-g1-migrator mais côté Duniter
s’assurer que la trésorerie ne crée pas de monnaie au genesis (elle doit être mise à existential deposit minimum, donc si elle est à zéro de la monnaie est ajoutée)
s’assurer qu’il y tous les check au genesis nécessaires à ne pas avoir d’incohérence de storage
Adapter py-g1-migrator pour la migration Ğ1
What’s needed to start a ĞTest network
Incohérence dans les données? – certifications expirées
V2S: Ğ1 data migration (g1-migrator)
Date de création du DU
Quantité de monnaie sur Duniter / Total issuance vs monetary mass
g1-migrator ==> seulement le sujet V2S: smooth gradual migration (clients and indexers side)
Pas sûr que je traite tout dans la même MR, nous verrons.