V2S: Ğ1 data migration (g1-migrator)

[poka]

Maintenant j’ai une autre question:

Pourquoi tous les comptes membres ont un consumer à 1 dès le début, ce qui empêche par exemple de migrer un compte legacy vers une nouvelle adresse (besoin de vider le compte)

Les simples portefeuilles, eux, n’ont pas ce consumer:

Je crois que ça a quelque chose avoir avec genesis_certs_expire_on, je me suis déjà pris la tête avec ça sans comprendre vraiment ce qui provoque ce consumer, ni ce qu’il faut reseigner comme valeur ici étant donné que les numéros de blocs d’expiration des certifications genesis sont inscrites individuellement dans le genesis.

Peut être est-ce en rapport avec la nécessité de finir de paramétrer le runtime de la ĞTest comme disait Elois ?

---

Second problème (peut être lié mais je ne pense pas):

Lorsque je tente de migrer un simple portefeuille, donc de le vider, pas de consumer donc gecko me permet de le faire, mais l’extrinsic débouche sur cette erreur:

Unable to retrieve header and parent from supplied hash

Je suis au bloc 135 donc il y a pourtant bien un hash parent.

Par contre une simple transaction d’un compte membre vers nouveau portefeuille fonctionne.

edit: Ah je pense savoir d’où venait ce bug, c’est que je suis resté connecté à Ğecko entre 2 reboot de gtest local, gecko reprend le fil nickel directement concernant les valeurs de storage, donc c’est super, mais débouche je pense sur cette erreur lorsqu’on tente d’exécuter n’importe quel extrinsic. Il faut donc déco/reco. Donc simplement need fix côté gecko qui peut détecter en cas de monnaie de test:
if new_blocnumber < last_blocnumber: déco/reco

---

Je sais que je pose beaucoup de questions… faut pas hésiter à me répondre “va lire le code” ^^
C’est juste que certains ici le connaissent bien mieux que moi, vous mettez beaucoup moins de temps à diag ces bugs que moi si je dois aller chercher dans le code v2s (quand j’y arrive…)

Avec plaisir pour se faire des sessions peer programing “analyse storage ĞTest et diags”

[poka]

@tuxmain / @HugoTrentesaux on pourrais se caller une visio « Consumers genesis & analyses » dans la semaine ?

[HugoTrentesaux]

Ouais, mais j’ai pas encore trop compris les consumers.

[poka]

Ce sera donc l’occasion ^^

[tuxmain]

Dans la semaine c’est compliqué, j’ai des examens et des travaux (la semaine prochaine aussi). Peut-être à partir de jeudi soir.

[1000i100]

Pour les clef que j’avais proposé de tester avec g1lib :

  d2meevcahfts2gqmvmrw5hzi25jddikk4nc4u1fkwrau 30Ǧ1
  afv1d5xa7fcdhcta1bqfq3pwvwem16gw67qj37obgnsv 20,84Ǧ1
  dyvfr3fqbs6g1yrktbstzxdkj3n7c5hrqf9buddzne4o 100Ǧ1
  11111111111111111111111111111111111111111111 50,75Ǧ1
  jUPLL2BgY2QpheWEY3R13edV2Y4tvQMCXjJVM8PGDvyd 60Ǧ1
  gatrpfmgsuez193bja5snivz3dsvsqn5kcm4ydtpknsy 225Ǧ1

Total < 500Ǧ1

Aucune des 6 ne passe en l’état.
Quoi que je change, les 3 premières ne passent pas.
La 4ème avec que des 1, si j’en enlève suffisamment pour qu’elle fasse 32 bit, elle passe coté point ed25519, mais pas pour les règles de longueur en b58 définie par Duniter.
Les 5 et 6ème ne passent pas en l’état, mais si je supprime le premier ou le dernier caractère, elles deviennent valides.
Du coup, pour les 2 dernières, je me demande comment elles ont été générées, mais il est possible qu’une clef privée soit associé aux versions avec 1 caractère de moins et qu’un bug de conversion et rajouté un caractère…
Si c’est le cas et que le bug est présent en sens inverse, il est peut-être possible de produire une transaction qui utilise ces fonds, mais ça me semble quand même hautement improbable.

Ce que je propose : expliciter lors de la migration que ces 6 clefs sont invalides dans la nouvelle version, qu’elles sont issue d’un bug, mais que si quelqu’un est capable de reproduire le bug en montrant qu’il dispose de la clef privée qui génère cette clef publique, on est ok à lui verser le montant qui était sur le compte avant migration s’il se manifeste moins d’1 an après la migration. (et si ça à lieu, tant qu’on est sous les 500Ǧ1, je veux bien verser le montant à partir de mes fonds propre)

[Maaltir]

Ce sont peut-être des versements faits sur des clés erronées.
La clé 111111… est improbable, et ressemble selon moi à de la destruction monétaire.

Du coup, si ces comptes ne sont pas repris, cela entrainera une diminution de la masse monétaire ?

Y a-t-il une capture vidéo de la dernière visio mensuelle ?

[vit]

La clef 1111 a été un test de @poka, donc on sait qui la créée.

Non, désolé, pas de vidéo, mais le pad de résumé est disponible.

[poka]

@Maaltir

Du coup, si ces comptes ne sont pas repris, cela entrainera une diminution de la masse monétaire ?

Non on peu compenser cette somme dans la caisse commune sans soucis.

[elois]

@poka

Pourquoi tous les comptes membres ont un consumer à 1 dès le début ?

Désolé je suis plus très dispo.
C’est normal pour les membres forgerons, car la pallet session “consomme” le compte pour stocker les sessions keys.
Par contre, ça ne devrait pas être le cas pour les comptes non-forgerons.

[poka]

@elois

C’est normal pour les membres forgerons, car la pallet session « consomme » le compte pour stocker les sessions keys.
Par contre, ça ne devrait pas être le cas pour les comptes non-forgerons.

En effet c’était en testant sur mon compte membre poka que j’observais ce consumer, hors il était dans le groupe smith… En le retirer de smith, le consumer est bien absent, et donc la migration identité + solde se passe sans soucis sur gecko.

Donc pour résumer, je n’observe plus de bugs concernant le storage ĞTest pour le moment.

Voici donc les points à aborder avant le lancement d’un live ĞTest:

• Détailler dans un ticket les changements à faire côté runtime entre ĞDev et ĞTest.
• Ne pas oublier le cas des certifications émises par des comptes non membre
• Éventuellement prévoir un bloc revoked username dans le genesis, et sa prise en charge côté Duniter
• Implémenter ces changements
• Créer des scripts python ou rust pour faciliter le lancement d’un live network, pour le paramétrage genesis avec les identités de dev, ajout au groupe smith avec certifications, comité tech. Ainsi que la génération et gestion des sessions keys. Pour le reste, ce qui concerne la visualisation des votes pour runtime upgrade, votation, tout ceci nécessitera un outil web dédié.

Vous voyez autre chose ?

[elois]

@poka

Vous voyez autre chose ?

Oui beaucoup d’autres choses, réaliser toutes les issues dont le milestone est " ğtest migration", il y en a beaucoup: ğtest migration · Milestones · nodes / rust / Duniter v2S · GitLab

Duniter-v2s est encore très loin d’être près pour une ĞTest, il faudrait d’abord que vous arriviez à relancer et maintenir une ĞDev

[poka]

@elois

Duniter-v2s est encore très loin d’être près pour une ĞTest, il faudrait d’abord que vous arriviez à relancer et maintenir une ĞDev

Peu importe son nom, mais le prochain reboot sera avec données G1.

[HugoTrentesaux]

Ce sera une ĞDev avec des données réelles issues de la Ğ1 qui permettront de concevoir les UI plus facilement (existence de données Cesium+ rattachées, nombre de certifications émises et reçues réalistes…). Son lancement se fera lors du hackathon de novembre, d’ici là il faut que je teste et finisse de documenter le processus (d’autres choses moins importantes mais plus urgentes avancent entre temps).

[poka]

Now Ğ1-migrator can help you to start a new ĞDev live network with up-to-date Ğ1 data from scratch:

[poka]

Le README est à jour (TL;DR): README.md · master · tools / py-g1-migrator · GitLab

[Pini]

J’essaie de comprendre un peu comment ça marche. Et il me manque une étape : comment sont extraites les données de duniter v1 ? J’ai tenté un dex export-bc mais ça ne produit pas ce qui est réclamé par le script python : il râle sur un fichier ud_value.json qu’il ne trouve pas.

[HugoTrentesaux]

Il semble que py-g1-migrator n’ait pas produit de fichier blocs.json depuis le 9 mai alors qu’il continue bien à produire les autres fichiers. @poka est-ce que tu as une idée de pourquoi ?

https://g1-migrator.axiom-team.fr/inputs/

blocs.json                                         09-May-2023 04:32            31764096
certs.json                                         29-May-2023 04:31            63171791
idty.json                                          29-May-2023 04:31             1507105
transactions_history.json                          29-May-2023 04:31            82388659
ud_value.json                                      29-May-2023 04:31                  45
wallets.json                                       29-May-2023 04:30             2675216

Et donc avec ces données le ./main.py plante en cherchant le bloc d’expiration d’une certification :

Generate ĞTest genesis with up-to-date Ğ1 data
    get ĞTest parameters...
    dump ĞTest parameters...
    parse identities...
Traceback (most recent call last):
  File "/home/hugo/dev/py-g1-migrator/./main.py", line 50, in <module>
    identities_wallets = get_identities_and_wallets(opt1)
  File "/home/hugo/dev/py-g1-migrator/lib/functions.py", line 82, in get_identities_and_wallets
    cert_expire_on_bloc = date_to_bloc_number(blocs[str(cert['writtenOn'])], start_timestamp)
KeyError: '625701'

[poka]

En effet, c’est la commande ./dex find main_blocks qui crash au bout d’une vingtaine de secondes:

$ time yes|./dex find main_blocks -p medianTime -o json
Database opened in 0.085576 seconds.
Killed

real	0m12.755s
user	0m18.913s
sys	0m15.138s

Là où les autres commandes dex fonctionnent correctement.
Malheureusement dex ne me donne aucune info sur la cause de ce crash.
Je suis sur Duniter v1.8.6 sur cette machine.

J’ai recompilé duniter depuis la branche dev sur mon pc, ainsi que dex, ça synchronise actuellement, je verrai si j’ai le même soucis ici.

Si oui il faudra soit debuguer dex, soit exporter les données de ces blocs autrement.

---

edit:

Bon va savoir pourquoi, en passant l’option -l 1000000 pour définir le nombre de ligne à exporter par dex, et bien la commande fonctionne correctement en exportant toutes les lignes…
A la base je souhaitais simplement isoler la ou les lignes posant problème, pour finalement me rendre compte qu’en voulant debuger, ça règle le problème…

J’ai donc mis à jours le script en conséquence pour contourner le soucis, qui semble donc venir de dex et non d’une db corrompu (ce que je redoutais).
Les données sont donc à jours.

[HugoTrentesaux]

Super, merci beaucoup pour ce fix, ça me permet de continuer à avancer sur le format du genesis gtest.

J’ai maintenant une POC qui respecte le bon format, il me reste deux champs à remplir :

"membership_expire_on": XXX,
"next_cert_issuable_on": XXX,

pour l’instant j’ai mis des valeurs bidon, et ça me permet de tester la cohérence du genesis en utilisant les tests implémentés en Rust : node/src/chain_spec/gtest_genesis.rs · 5d8ba754739157d7697f6e6396f75c8a6b961fde · nodes / rust / Duniter v2S · GitLab

Ça m’a permis de trouver une incohérence dans les données : les membres du comité technique sont censés être membres, mais dans idty.json on trouve :

  {
    "key": "D9D2zaJoWYWveii1JRYLVK3J4Z7ZH3QczoKrnQeiM6mx",
    "value": [
      {
        "member": false,
        "uid": "elois",
        "writtenOn": 624084
      }
    ]
  },

alors que elois est censé être toujours membre de la Ğ1. Peut-être un problème en sortie de dex ?