V2S: Ğ1 data migration (g1-migrator)

Nodes Duniter-v2s
21

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.

2 Likes
22

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'
1 Like
23

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… :man_shrugging:

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.

3 Likes
24

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 ?

25

Et bien non, les données sont correctes, @elois n’est plus membre de la Ğ1: https://wotwizard.axiom-team.fr/fr/membres/profil?hash=4C4A05D4D36D5E374C8FC950247F34FDABF465272AAF591A7E49509C953B886E

Il n’a pas renouvelé son adhésion.

1 Like
26

Ah oui, en effet, j’avais regardé sur Cesium par habitude et je devais être sur un nœud désynchronisé :thinking:. Merci ! Entre temps j’ai ajouté le champ next_cert_issuable_on mais il me reste à trouver comment obtenir la date d’expiration de l’adhésion avec dex.

27

Choses à faire dans py-g1-migrator avant de pouvoir lancer une ǦTest:

  • récupérer l’information de la initial_monetary_mass pour la mettre dans le genesis
  • remplir la valeur du champ membership_expire_on avec le bloc d’expiration de l’adhésion
  • remplir la valeur du champ next_cert_issuable_on avec le numéro de bloc de la prochaine certification qu’une identité peut émettre
  • utiliser les mêmes index que Duniter +1 ou DataJune (exemple https://files.datajune.coinduf.eu/global/pseudos.txt avec numéro de ligne = identity index)
28

Les points ci-dessus sont quasiment terminés dans ma branch hugo-gtest. Il reste à relire et à corriger les points suivants :

  • corriger date de réévaluation du DU
  • décider si l’heure du premier DUv2 est un problème (Date de création du DU)
  • récupérer l’adresse de la trésorerie pour déplacer la monnaie ignorée
  • utiliser le bon préfixe ss58 pour les addresses
  • comprendre pourquoi la masse monétaire n’est pas strictement égale à la somme des comptes et corriger (cf Quantité de monnaie sur Duniter)
  • valider que les conversions timestamp → nombre de blocs se font côté py-g1-migrator (implique un léger décalage de timing sur les expirations de certification par exemple, cf utilisations de date_to_bloc_number)
2 Likes
29

Oui le README ne focalise pas du tout dessus : mais tout se trouve dans le fichier export-from-v1.8.sh.

En tout cas merci @poka pour cet outil, ça me facilite grandement la tâche.

1 Like