V2S: Ğ1 data migration (g1-migrator)

Nodes Duniter-v2s
1

please see readme for more info: README.md · master · tools / py-g1-migrator · GitLab

Ce dépôt vous permet de générer le JSON genesis v2s pour votre ĞTest local, contenant donc toutes les données de la blockchain Ğ1:

Le JSON genesis par defaut peut être récupéré directement à cette adresse:
https://g1-migrator.axiom-team.fr/genesis/gtest.json

Le readme explique son fonctionnement ainsi que les sources de données.

Cette discutions à pour but d’analyser ces données et de réfléchir aux modifications nécessaires côté Duniter v2s au niveau du parsing genesis.

1 Like
2

Voici un état du storage que je ne comprends pas:

Pour l’identité Damery:

  • pubkey v1: HJ7U5CeYLQZrP76yRP7WgHnMvJggxeTTYW8wDJDwf42f
  • address v2: 5HYA7UjumodTMsokRJm7zBvGPySSAjEEqPaSLHfV9sw5CtMN
  • Certifications reçus dans le jsons genesis: 44 (c’est le bon chiffre, vous verrez sur Cesium que 2 de ses 46 certifications proviennent de non membres, qui eux sont filtrés dans mon genesis)

Ensuite dans le storage:

cert.certsByReceiver: Vec<(u32,u32)>

[
  [
    30
    1,118,762
  ]
  [
    119
    2,029,354
  ]
  [
    302
    3,065,959
  ]
  [
    331
    7,413,134
  ]
  [
    437
    2,310,473
  ]
  [
    500
    8,833,276
  ]
  [
    504
    2,546,931
  ]
  [
    510
    7,412,034
  ]
  [
    1,048
    6,475,232
  ]
  [
    1,179
    5,929,103
  ]
  [
    1,286
    9,515,699
  ]
  [
    1,287
    324,980
  ]
  [
    1,331
    5,903,576
  ]
  [
    1,339
    9,867,941
  ]
  [
    1,500
    4,157,608
  ]
  [
    1,593
    8,665,021
  ]
  [
    1,786
    8,776,916
  ]
  [
    2,179
    955,177
  ]
  [
    2,527
    1,520,893
  ]
  [
    2,658
    3,270,125
  ]
  [
    2,998
    2,152,810
  ]
  [
    3,015
    7,213,662
  ]
  [
    3,064
    5,990,904
  ]
  [
    3,087
    4,171,217
  ]
  [
    3,152
    1,869,456
  ]
  [
    3,224
    2,216,094
  ]
  [
    3,257
    3,954,727
  ]
  [
    3,683
    5,150,291
  ]
  [
    3,861
    5,596,018
  ]
  [
    3,868
    4,688,878
  ]
  [
    3,879
    4,705,238
  ]
  [
    4,185
    3,179,969
  ]
  [
    4,240
    1,729,956
  ]
  [
    4,562
    7,219,638
  ]
  [
    4,574
    2,319,689
  ]
  [
    4,658
    2,671,141
  ]
  [
    4,761
    6,519,124
  ]
  [
    4,836
    4,716,496
  ]
  [
    5,457
    1,867,470
  ]
  [
    5,564
    5,588,509
  ]
  [
    5,979
    1,926,421
  ]
  [
    6,222
    2,943,451
  ]
  [
    6,236
    4,171,217
  ]
  [
    6,253
    8,994,198
  ]
]

44, le compte y est donc super.

Mais par contre la valeur de storage cert.storageIdtyCertMeta["receivedCount"] vaut 10 !

image
image1796×745 110 KB

Comment est-ce possible.
Vous verrez que c’est le cas pour presque toutes les identités, cert.storageIdtyCertMeta["receivedCount"] vaut moins que ce qui est contenu dans cert.certsByReceiver

Je précise qu’il n’y a que les membres actuels dans le genesis.

1 Like
3

J’ai peut-être trouvé un truc bizarre dans pallets/certification/src/lib.rs#L141 : en itérant sur les certificateurs d’une identité, on initialise leur IdtyCertMeta s’il n’en ont pas encore, mais avec received_count à la valeur du nombre de certifs reçues par l’identité qu’ils ont certifiée. Et on ne corrige pas ce nombre plus tard.

Je vais essayer de corriger ça, mais il manque des pubkeys dans ton json :
Error: Input("Error parsing gen conf file: missing field pubkey at line 121616 column 5")

Edit: fix(cert): genesis: wrong received_count in StorageIdtyCertMeta (!115) · Merge requests · nodes / rust / Duniter v2S · GitLab

3 Likes
4

J’ai fix la pubkey manquante, ça rends mon parsing toujours un peu plus tricky dû au fait que les données primaires (dex) sont ordonnées par certifications envoyés et non reçus. Mais c’est commenté, et ça marche (7s d’exec à partir de données remote, donc ça va encore).

Super je test ton fix quand la pipeline de fusion est terminé!

edit: bravo @tuxmain le bug semble résolu !

image
image1787×567 78.4 KB

44 et non 10 :slight_smile:

2 Likes
5

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)

image
image1832×553 108 KB

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

image
image1877×557 108 KB

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”

6

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

1 Like
7

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

1 Like
8

Ce sera donc l’occasion ^^

1 Like
9

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

1 Like
10

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)

2 Likes
11

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 ?

12

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.

2 Likes
13

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

14

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.

1 Like
15

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 ?

1 Like
16

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 :wink:

2 Likes
17

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

18

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).

1 Like
19

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

:slight_smile:

4 Likes
20

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