Python script to generate Ğ1v2 genesis json

Nodes Duniter-v2s
1

edit: Voici le dépôt du script de migration: tools / py-g1-migrator · GitLab

Avec @HugoTrentesaux on pense que ce serait une bonne idée de commencer à tester de notre côté la génération du genesis g1v2 à partir de données réelles.

Ca permettra d’approfondir nos tests, et d’ouvrir un peu plus large le cercle des alpha testeurs pour les clients si nous décidons de booter une gtest (donc données Ğ1) dans les mois qui viennent.

J’ai fait un pad où je déroule un peu mon raisonnement technique pour y voir plus claire.

Nous aurions bien besoin de petits scripts microservices qui permettent certaines étapes, et quoi de mieux que Python pour faire ça :smiley:

J’aimerais commencer avec ces données:

import json, pprint
from urllib.request import urlopen

f = urlopen("https://g1-stats.axiom-team.fr/data/forbes.json")
inputData = json.load(f)
identedInputData = pprint.pformat(inputData)

print(identedInputData)

Pour info les données de ce json g1-stats proviennent de cette requête GVA: jaklis/gvaWallets.py at master - jaklis - P2Git

Je pense qu’il faudra faire quelques ajouts très rapides côté GVA pour nous faciliter la vie pour la migration.

J’explique dans le pad qu’il manquera d’abords les certifications émises et reçus, ce qui suffira à faire des tests à blancs avec compteurs de date de certifs à zero, ni distances.
Puis il faudra ajouter les dates de chaque certifications émises. Mais pour ça il faudra adapter côté Duniter v2s la prise en charge de ces paramètres supplémentaires pour le genesis.
Pour le moment on peut déjà faire sans les dates pour tester.

Je n’ai jamais touché à la lib substrate python, et je n’ai pas forcément envie de me lancer là dedans.

@vit @Moul @matograine est-ce que ça vous dirais de faire ça ?
Il me faudrait surtout la conversion pubkey v1 → address ss58 v2s, j’imagine que c’est plus simple en utilisant la lib python substrate et que vous avez dû commencé à trifouiller dedans ^^

Ensuite il suffira de bien formater chaque données et bien formater le document en s’inspirant de gdev.sjon (je crois même que Elois a déjà créé gtest.json quelque part sur une branche)

1 Like
2

Voilà pour la conversion d’adresse en Python 3. Nécessite la bibliothèque substrate-interface.

from base58 import b58decode
from substrateinterface import Keypair, KeypairType

address_v1 = "DCovzCEnQm9GUWe6mr8u42JR1JAuoj3HbQUGdCkfTzSr"
address_V2_target = "5GAT6CJW8yVKwUuQc7sM5Kk9GZVTpbZYk9PfjNXtvnNgAJZ1"

# get public key in bytes from V1 address
pubkey = b58decode(address_v1.encode("utf-8"))

# get incomplete Substrate keypair (only public key) from public key bytes
keypair = Keypair(public_key=pubkey, ss58_format=42, crypto_type=KeypairType.ED25519)

# get V2 address
address_V2 = keypair.ss58_address

# check V2 address
assert address_V2 == address_V2_target

print(address_V2)
3 Likes
3

Merci !

Par contre sur certaines pubkey comme 29jU5DNXwM4QyR7uuVuPRS8ZRfG3zzuM3p9EiYmsp6d, elle ne fait pas 32 bytes donc j’ai cette erreur:

Traceback (most recent call last):
  File "./main.py", line 30, in <module>
    address_v2 = v1PubkeyToV2Address(profile['pubkey'])
  File "./main.py", line 15, in v1PubkeyToV2Address
    keypair = Keypair(public_key=pubkey, ss58_format=42, crypto_type=KeypairType.ED25519)
  File "/home/poka/.local/lib/python3.8/site-packages/substrateinterface/base.py", line 119, in __init__
    raise ValueError('Public key should be 32 bytes long')
ValueError: Public key should be 32 bytes long
4

C’est pas l’histoire des clefs qui commencent par 1 ou pas ? A creuser, je crois que @matograine avait bien poncé le sujet…

1 Like
5

J’arrive à transformer les 26149 pubkey Ğ1 en address v2s depuis ce json, qui est ordonné par ordre alphabétique des pubkey, par ce subterfuge:

if i < 98 and pubkey[0] != '1' and pubkey_lenght < 44:
    pubkey = '1' + pubkey

Là tout se passe bien, mais je ne saurais pas expliquer pourquoi.
Pour mes tests ça me va, il faudra bien sûr mieux identifier la source du problème avant migration.

Mon code est ici si vous voulez essayer: main.py · master · pokapow / py-g1-migration · GitLab

6

On peut aussi compléter le résultat de b58decode avec des zéros, ce qui devrait être plus sûr en cas de clé malformée (<43 caractères) :

pubkey_incomplete = base58.b58decode(pubkey_g1)
assert len(pubkey_incomplete) <= 32
pubkey = bytes([0]*(32-len(pubkey_incomplete))) + pubkey_incomplete
3 Likes
7

Super merci !

Du coup j’ai remplacé par cette condition bien plus pertinente:

    pubkey_bytes = base58.b58decode(pubkey)
    pubkey_lenght = len(pubkey_bytes)
        
    if pubkey_lenght < 32:
        pubkey_bytes = bytes([0]*(32-len(pubkey_bytes))) + pubkey_bytes

Et ça marche, je convertis toutes les clés Ğ1 avec succès !

A noter qu’on peut aussi directement faire ceci sans condition en effet:

    pubkey_bytes = base58.b58decode(pubkey)
    pubkey_bytes = bytes([0]*(32-len(pubkey_bytes))) + pubkey_bytes

Le résultat est le même.

Je peux attaquer le formatage du document final.
Il ne manquera “que” les noms d’identités certifiés par identités, avant de pouvoir tester une blockchain gtest avec compteur de dates certifs à zero.

Je crains que ce soit plus compliqué que prévus d’ajouter ces données à la requête wallets de GVA, car je me souviens maintenant que GVA n’avais pas encore accès à la DB wot c’est bien ça ?

Tu en pense quoi @tuxmain ?
Vous une idée pour récupérer ces données sans scrapper chaques pubkey avec BMA et que ça prenne 6h à exécuter ? ES Cs+ ? gql WotWizard @gerard94 @HugoTrentesaux ? Datajune ?

2 Likes
8

Ça serait pas plus simple de tout récupérer dans la bdd ?

Sinon il y a le JSON de la worldwotmap et celui de la wotmap qui contiennent toutes les certifications.

Il me semble que GVA donne à peu près tout (y compris les username) sauf les certifications.

9

Si je comprends bien, tu veux obtenir le pseudo d’une identité en blockchain à partir de sa clé publique ?
La requête graphQL (POST) suivante envoyée au serveur WotWizard https://wwgql.coinduf.eu (quand il fonctionne) devrait te renvoyer ce que tu cherches au format JSON (remplacer <pubkey> par sa valeur) :

{"query":"query($pubkey:String!){idSearch(with:{hint:$pubkey}){ids{uid}}}","variables":{"pubkey":"<pubkey>"}}
10

Non, je veux le nom de chaque identité certifié par chaque identité, pour générer le genesis g1 v2s.

Avec les json fournis par tuxmain, je pense que ça le fait!

11

Ah, OK. WotWizard le fait aussi facilement, tu as le choix.

1 Like
12

@gerard94 du coup est-ce que tu pourrais me mettre ici une requête wot-wizard qui sorte ce genre de donnée :

"identities": {
    "elois": {
      "balance": 154623,
      "certs": [
        "poka",
        "cgeek",
        "vit",
        ...
      ],
      "pubkey": "D9D2zaJoWYWveii1JRYLVK3J4Z7ZH3QczoKrnQeiM6mx"
    },
    "truc": {
      "balance": 42531,
      "certs": [
        "machin",
        "machine",
        ...
      ],
      "pubkey": "Do99s6wQR2JLfhirPdpAERSjNbmjjECzGxHNJMiNKT3P"
    }
    ...
  }

Pour chacune des 6435 identités ?
certs correspond ici aux noms d’identités certifiés (issuer)

Seconde question, est-ce que wotwizard peut aussi sortir la date d’émission de chaque certifications ? Tu as le nom du champ en question ?

13

Je me demande si la date de validation d’une certification ne serai pas plus pertinente que sa date d’émission.
Car c’est bien celle là qui indique si on est disponible pour certifier à nouveau.
Si j’ai bien compris les deux seront confondues dans Duniter V2…

1 Like
14

Je croyais comme toi @Maaltir jusqu’à ce que je comprenne que c’est la date d’émission et non de validation qui compte pour l’expiration de la certification (cf Plus de 100 certifications? - #9 par cgeek). @poka j’ai bien vu ce fil, je voulais ajouter des fonctionnalités dans Datajune pour répondre à ce besoin, mais j’ai pas trop eu le temps dans le train Paris → Toulouse :slight_smile:

2 Likes
15

Pour faire les choses proprement (en respectant jour pour jour les délais d’émission et d’expiration) on pourra même prendre les deux dates. Mais actuellement le programme de génération du bloc zéro de la gdev-v2 prend ces deux dates en paramètres globaux (c’est-à-dire qu’au début de la gdev, tous les membres deviennent disponibles pour certifier au même bloc, et leurs certifications initiales ont la même date d’expiration).

Il faudra évidemment changer ça pour la migration.

16

Oui, mais ce n’est pas parce qu’un truc n’est pas très bien fait dans Duniter V1 qu’il faut faire pareil dans V2. :innocent:
Me trompe-je quand je dit que les deux seront confondus dans V2 ?

D’ailleurs, je suppose que les certifs en attente en piscine, ne seront pas reprises dans Duniter V2 ?

17

Non

1 Like
18

Tu parles de avant ou après le commit 6f4789bd8c8ee9e81cefe0a2ce6a3a72e6f38b41 ?

1 Like
19

Ah chouette, j’avais seulement regardé gdev.json, pas le code.

20

Ou @Paidge peut être ?