Python script to generate Ğ1v2 genesis json

Nodes Duniter-v2s
82

ce n’est pas une identité bizarre, juste un IdtyIndex qui ne correspond à rien (ni métadonnées, ni nom), c’est déjà comme ça que sont représentées les identités retirées d’après ce que j’ai compris du code. Actuellement dans Duniter on peut retirer une identité alors qu’elle a encore des certifications émises, ça ne pose pas de problème, vu que l’IdtyIndex ne sera jamais réutilisé.

Et je ne compte pas les retirer juste après, mais au bloc zéro directement. Ça revient un peu à ce que tu proposes avec le nombre d’identités configurables, mais ça permet de garder un IdtyIndex qui a un peu de sens, au moins historique.

Pour info, ça fait longtemps que j’utilise un IdtyIndex dans DataJune, on peut tout simplement réutiliser celui là qui correspond à l’ordre d’apparition dans l’archive json de la blockchain que j’ai utilisée pour ça.

PS:
C’est peut-être inutile, mais ça me ferait plaisir qu’en interne, les IdtyIndex des 59 identités du bloc zéro soient numérotées de 1 à 59 :slight_smile:

1 Like
83

Donc soit remplacer le map json par un tableau et l’ordonner par joined_on, soit ajouter dans le json le joined_on, mais ça serait bizarre puisque substrate n’utilise pas cette donnée par la suite. Donc je suis plutôt pour la première solution, ce qui a aussi l’avantage de faciliter le debug (idty_index = indice dans le json).

2 Likes
84

Un message a été fusionné à un sujet existant : V2s Ğ1 data migration

85

J’ai enlevé la step 1 du dépôt, ainsi dex et les inputs data n’y sont plus.
Le genesis gtest.json a également été retiré.

Les données sont désormais directement récupérés depuis cette adresse: https://g1-migrator.axiom-team.fr
Le readme est à jour.

J’ai ajouté un dossier custom/ où vous pouvez facilement ajouter des identités customs, définir groupe smith, comité tech et les paramètres de la monnaie.

Le genesis final est désormais accessible sur ce même serveur directement, généré 1 fois par jour dans la foulé: https://g1-migrator.axiom-team.fr/genesis/gtest.json

Il est exposé par nginx donc beaucoup plus lisible dans le navigateur que depuis le gitlab raw.

Donc pas besoin de CI @vit je pense en fait, ça ira très bien comme ça non ?

J’ai supprimé les artefacts indésirables dans l’hisrotique git

$ git filter-repo --invert-paths --path dex --path input/ --path output/
$ git push -f
$ du -hs .git
22M     .git

Je ferme ce topic brouillon pour en ouvrir un nouveau maintenant que le dépôt est propre:

2 Likes
87

Il faut mettre ça avec un gros warning dans le readme de py-g1-migrator, sinon on risque de prendre ça pour acquis ><

Ah non en fait alors

Ah mais ça par contre il faut le mettre

Bref, je relis ce sujet et je me rends compte qu’il s’est passé beaucoup de choses, j’ai pas été tellement utile sur ce coup. Mais maintenant je suis en mesure de changer le parsing du genesis. À chaud comme ça je dirais :

  • ce serait vraiment chouette de conserver les idty index de la v1. En terme de suivi c’est mieux que d’avoir des “extra certs” avec un mapping implicite
  • je pense qu’on peut mettre les identités v1 dans le genesis avec un removable_on à zéro, ça permet de garder une trace de la v1 dans le genesis
1 Like
88

Pourquoi est-ce que tu n’appliques pas la fonction prune_identities au bloc zéro ?

fn on_initialize(n: T::BlockNumber) -> Weight {
    if n > T::BlockNumber::zero() {
        Self::prune_identities(n)
    } else {
        0
    }
}

Ça me paraît simple d’ajouter les identités avec un expire_on: 0 et removable_on: 0 de telle sorte que l’adhésion expire dès le bloc zéro et que l’identité correspondante puisse être retirée dès le bloc zéro.

Peux-tu détailler ? Est-ce parce que le storage est écrit dans le genesis et que la fonction on_initialize ne s’y applique pas?

1 Like