Python script to generate Ğ1v2 genesis json

poka · 7 October 2022 22:22

Mais oui c’était juste ça, merci !!
En plus on a un bol absolu, car l’identité n°1 alphabétiquement dans la Ğ1, c’est 1000i100 mdr

Donc si je résume pour @1000i100 , pour fix le bug, il suffit de te rajouter dans la toile forgerons, tu n’a pas le choix, sinon on peut pas migrer la Ğ1, c’est quasiment écrit dans le code mdr
Tu es notre Alice de la Ğ1.

Donc le fix est coté py-g1-migration:

smiths.update({'1000i100': {'certs': ['elois', 'HugoTrentesaux', 'vit', 'poka']}})

→

    "1000i100": {
      "certs": [
        "elois",
        "HugoTrentesaux",
        "vit",
        "poka"
      ]
    }

→

$ rm -rf data/chains/ && docker compose up
[+] Running 1/0
 ⠿ Container duniter-v2s  Created                                                                                                                                                                                               0.0s
Attaching to duniter-v2s
duniter-v2s  | Starting duniter with parameters: --name duniter_local --dev -d /var/lib/duniter --unsafe-rpc-external --unsafe-ws-external
duniter-v2s  | 2022-10-07 22:20:22 Duniter    
duniter-v2s  | 2022-10-07 22:20:22 ✌️  version 0.3.0-386e4d846c7    
duniter-v2s  | 2022-10-07 22:20:22 ❤️  by Axiom-Team Developers <https://axiom-team.fr>, 2021-2022    
duniter-v2s  | 2022-10-07 22:20:22 📋 Chain specification: Development    
duniter-v2s  | 2022-10-07 22:20:22 🏷  Node name: duniter_local    
duniter-v2s  | 2022-10-07 22:20:22 👤 Role: AUTHORITY    
duniter-v2s  | 2022-10-07 22:20:22 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full    
duniter-v2s  | 2022-10-07 22:20:22 ⛓  Native runtime: gdev-300 (duniter-gdev-1.tx1.au1)    
duniter-v2s  | 2022-10-07 22:20:27 🔨 Initializing Genesis block/state (state: 0xc9f0…2757, header-hash: 0x3774…66ab)    
duniter-v2s  | 2022-10-07 22:20:28 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.    
duniter-v2s  | 2022-10-07 22:20:29 👶 Creating empty BABE epoch changes on what appears to be first startup.    
duniter-v2s  | 2022-10-07 22:20:29 Using default protocol ID "sup" because none is configured in the chain specs    
duniter-v2s  | 2022-10-07 22:20:29 🏷  Local node identity is: 12D3KooWDGfNB6Cit5YHx1ExWMYWvBdYdbfQXdSKzvyfEz9yJ2bj    
duniter-v2s  | 2022-10-07 22:20:29 👶 Starting BABE Authorship worker    
duniter-v2s  | 2022-10-07 22:20:30 💻 Operating system: linux    
duniter-v2s  | 2022-10-07 22:20:30 💻 CPU architecture: x86_64    
duniter-v2s  | 2022-10-07 22:20:30 💻 Target environment: gnu    
duniter-v2s  | 2022-10-07 22:20:30 💻 CPU: AMD Ryzen 7 3700X 8-Core Processor    
duniter-v2s  | 2022-10-07 22:20:30 💻 CPU cores: 8    
duniter-v2s  | 2022-10-07 22:20:30 💻 Memory: 32044MB    
duniter-v2s  | 2022-10-07 22:20:30 💻 Kernel: 5.15.0-43-generic    
duniter-v2s  | 2022-10-07 22:20:30 💻 Linux distribution: Debian GNU/Linux 10 (buster)    
duniter-v2s  | 2022-10-07 22:20:30 💻 Virtual machine: no    
duniter-v2s  | 2022-10-07 22:20:30 📦 Highest known block at #0    
duniter-v2s  | 2022-10-07 22:20:30 〽️ Prometheus exporter started at 127.0.0.1:9615    
duniter-v2s  | 2022-10-07 22:20:30 Running JSON-RPC HTTP server: addr=0.0.0.0:9933, allowed origins=None    
duniter-v2s  | 2022-10-07 22:20:30 Running JSON-RPC WS server: addr=0.0.0.0:9944, allowed origins=None    
duniter-v2s  | 2022-10-07 22:20:30 ***** Duniter has fully started *****    
duniter-v2s  | 2022-10-07 22:20:30 🙌 Starting consensus session on top of parent 0x3774b04331fd44538c8e0574622bc68afe69b7ed91ca0b8c81225a77315a66ab    
duniter-v2s  | 2022-10-07 22:20:30 🎁 Prepared block for proposing at 1 (8 ms) [hash: 0x0b940f27ea4f9d98448b5ffacecef9e5df4c9468fd42814e353635bc7ae8690e; parent_hash: 0x3774…66ab; extrinsics (1): [0xaaba…1240]]    
duniter-v2s  | 2022-10-07 22:20:30 🔖 Pre-sealed block for proposal at 1. Hash now 0x0beb699f048426a4f3b690aed73e8f309c0079c45b2e0949b8c64e2f803f809c, previously 0x0b940f27ea4f9d98448b5ffacecef9e5df4c9468fd42814e353635bc7ae8690e.    
duniter-v2s  | 2022-10-07 22:20:30 👶 New epoch 0 launching at block 0x0beb…809c (block slot 277530205 >= start slot 277530205).    
duniter-v2s  | 2022-10-07 22:20:30 👶 Next epoch starts at slot 277530805    
duniter-v2s  | 2022-10-07 22:20:30 ✨ Imported #1 (0x0beb…809c)    
duniter-v2s  | 2022-10-07 22:20:35 💤 Idle (0 peers), best: #1 (0x0beb…809c), finalized #0 (0x3774…66ab), ⬇ 0 ⬆ 0    
duniter-v2s  | 2022-10-07 22:20:36 🙌 Starting consensus session on top of parent 0x0beb699f048426a4f3b690aed73e8f309c0079c45b2e0949b8c64e2f803f809c    
duniter-v2s  | 2022-10-07 22:20:36 🎁 Prepared block for proposing at 2 (3 ms) [hash: 0x9fd10c63d3a2ac37a71b42a2206989cad7883ec3bb695d337e595a7030da6994; parent_hash: 0x0beb…809c; extrinsics (1): [0x7273…de88]]    
duniter-v2s  | 2022-10-07 22:20:36 🔖 Pre-sealed block for proposal at 2. Hash now 0xf18b30a8b82e3f70013268293b6b4fb1bd6e2881f04bc01086bb038901eabdca, previously 0x9fd10c63d3a2ac37a71b42a2206989cad7883ec3bb695d337e595a7030da6994.    
duniter-v2s  | 2022-10-07 22:20:36 ✨ Imported #2 (0xf18b…bdca)    
duniter-v2s  | 2022-10-07 22:20:40 💤 Idle (0 peers), best: #2 (0xf18b…bdca), finalized #0 (0x3774…66ab), ⬇ 0 ⬆ 0    
duniter-v2s  | 2022-10-07 22:20:42 🙌 Starting consensus session on top of parent 0xf18b30a8b82e3f70013268293b6b4fb1bd6e2881f04bc01086bb038901eabdca    
duniter-v2s  | 2022-10-07 22:20:42 🎁 Prepared block for proposing at 3 (4 ms) [hash: 0x2d479de798b1b2ef8323da3643b06287e5352c3fde17df9de276897a59e3faf5; parent_hash: 0xf18b…bdca; extrinsics (1): [0x747f…b930]]    
duniter-v2s  | 2022-10-07 22:20:42 🔖 Pre-sealed block for proposal at 3. Hash now 0xa50dd48cd420139e25841a4cf9ebfc0eae63d30e63882dd3c0592b7488ce7572, previously 0x2d479de798b1b2ef8323da3643b06287e5352c3fde17df9de276897a59e3faf5.    
duniter-v2s  | 2022-10-07 22:20:42 ✨ Imported #3 (0xa50d…7572)    
duniter-v2s  | 2022-10-07 22:20:45 💤 Idle (0 peers), best: #3 (0xa50d…7572), finalized #0 (0x3774…66ab), ⬇ 0 ⬆ 0    
duniter-v2s  | 2022-10-07 22:20:48 🙌 Starting consensus session on top of parent 0xa50dd48cd420139e25841a4cf9ebfc0eae63d30e63882dd3c0592b7488ce7572    
duniter-v2s  | 2022-10-07 22:20:48 🎁 Prepared block for proposing at 4 (4 ms) [hash: 0x115496e52c130875bdcf7e2df5c56c31c585ebad2bddedcbe8b626a3844b8638; parent_hash: 0xa50d…7572; extrinsics (1): [0x205f…af66]]    
duniter-v2s  | 2022-10-07 22:20:48 🔖 Pre-sealed block for proposal at 4. Hash now 0xf95a391ed460ab53383b10abfb67ab33803175a5c7b11357a343bb2a67deadf6, previously 0x115496e52c130875bdcf7e2df5c56c31c585ebad2bddedcbe8b626a3844b8638.

J’ai une (quasi) ĞTest v2s en local !

Vous pouvez essayer: https://git.duniter.org/pokapow/py-g1-migration/-/raw/master/gtest.json

Je rappel que:

Toutes les certifications sont présentes, même les périmés, dû à l’indexation incrémental de DataJune
Il y a 31 comptes en moins car trop récents, dû à DataJune pas à jours
Les compteurs de dates de certifications sont tous à 0
Il n’y a que les membres actuels (moins 31…), pas les simples portefeuilles
Les nom d’identité révoqués ne sont pas pris en comptes, donc vous pourrez recréer une identité précédemment révoqué.

Pour le moment je ne vois pas d’autres points.

Pour la suite, comme le dis @elois maintenant il faudrait sortir les données complètes de Dex directement, avec les dates de certifications, dans un json simple que je peux reparser derrière pour formater le final.

elois · 7 October 2022 23:31

Ce n’est pas un bug, c’est un comportement que j’ai codé volontairement, et qui ne s’applique que pour une blockchain locale, donc une blockchain qui ne doit jamais être exposée publiquement sur internet.

Ce comportement n’existe pas pour le lancement d’un live network, en contre-partie les sessions keys doivent être renseignées à la main dans la genesis conf.

Ce qu’on appelle un live network (c’est du vocabulaire substrate), c’est un réseau qui peut être exposé publiquement, entre autres, car il utilise des vraies clés privées générées par celui qui bootstrap le réseau au lieu des clés de comptes de tests, mais il y a également d’autres différences.

Tu peut les rajouter en ajoutant le champ “wallets” au 1er niveau de profondeur, selon ce format:

{
  ..
  "wallets": {
    "5C4puptPcKQKxJjzwjxGo2kZoUvPGEivShnbAYBr7mbnNGcR": 31987,
    "5C5ANywaswtfr4bQvoMTbLjmQBLpBZAqUeD4eN2Ag46URgkc": 45300
  }
}}

Les montants sont exprimés en centimes de Ğ1.

Mais surtout pour lancer une ĞTestv2 il faudrait finir le développement du runtime gtest, qui est une copie du runtime gdev mais avec des constantes pour les paramètres (qui ne sont donc pas déclarés dans le genesis) pour des raisons d’optimisation.
Cette copie duplique une partie du code, ce qui permettra à l’avenir de n’activer certaines fonctionnalités d’abord que coté gdev, puis plus tard coté gtest.

poka · 8 October 2022 00:39

Oui j’avais compris, mais je trouve ça drôle quand même ^^

ok je me rends pas compte de ce qu’il reste à faire à ce niveau, si tu pouvais faire un point avec hugo ou tuxmain à l’occasion ce serait sympa, qu’on puisse booter une ĞTest live dans les mois qui viennent.

tuxmain · 8 October 2022 05:55

Le plus pratique serait peut-être de créer une identité !god (qui est alphabétiquement avant toutes les identités Duniter v1) avec la clé //alice.

poka · 8 October 2022 12:22

Non vue que c’est que pour les tests locaux c’est bon, on a 1000i100 !

poka · 10 October 2022 04:32

Voilà je viens de stabiliser le repo et ajouter le README: pokapow / py-g1-migration · GitLab

Tout y est détaillé pour extraire et exporter les données en moins de 5 minutes.

Si vous voulez utiliser le genesis final directement, c’est ici: https://git.duniter.org/pokapow/py-g1-migration/-/raw/master/output/gtest.json

Toutes les identités (membres et non membres) sont présentes, toutes leurs certifications avec numéro de bloc d’expiration, ainsi que tous les wallets, avec les soldes correctes. Tout provient de Dex.

Le binaire dex est directement dans le repo, il est utilisé par le premier script d’export des données primaires.

J’ai configuré les paramètres de la wot selon ce qui me semble refléter au mieux les paramètres Ğ1 actuels, tous est paramétrable dans currency_parameters.py
La valeur du premier DU est récupéré depuis Dex directement (dernière valeur de DU en date).

Selon moi, il ne manque que la liste des identités révoqués, mais cela nécessite un apport côté parsing genesis v2s.

Dites moi si vous voyez d’autres manques ou de mauvaises données.

Maintenant il va falloir analyser en détails l’état du storage v2s, voir si les données sont cohérentes.
Je vois par exemple que des identités n’ayant qu’une certification sont membres dans le storage, ce qui n’est pas normal.
Probablement un bug a régler côté Duniter, ou bien la déclaration des identités genesis non membres n’est pas encore pris en charge côté v2s.

Est-ce qu’un admin du gitlab pourrait déplacer ce dépôt au bon endroit svp ? (je ne sais pas où…)

enjoy

Maaltir · 10 October 2022 11:00

Les certifications renouvelées apparaissent 2 fois, est-ce normal ?
Et je ne vois pas les wallets avec leurs soldes.

poka · 10 October 2022 12:45

Non, as-tu un exemple stp ? J’ai peut être juste oublié un filtre quelque part.

Si il faut que tu regardes tout en bas du json, il est très gros…
Il y a un bloc wallets après le bloc identities.

J’ai oublié de préciser qu’il y a 6 wallets en moins, ce sont en fait 6 pubkey qui font plus de 32 bytes, je ne sais pas comment les traiter pour les convertir en address ss58 du coup:

# Remove pubkeys > 32 bytes
# d2meevcahfts2gqmvmrw5hzi25jddikk4nc4u1fkwrau
# afv1d5xa7fcdhcta1bqfq3pwvwem16gw67qj37obgnsv
# dyvfr3fqbs6g1yrktbstzxdkj3n7c5hrqf9buddzne4o
# 11111111111111111111111111111111111111111111
# jUPLL2BgY2QpheWEY3R13edV2Y4tvQMCXjJVM8PGDvyd
# gatrpfmgsuez193bja5snivz3dsvsqn5kcm4ydtpknsy
pubkey_bytes = base58.b58decode(pubkey)
pubkey_lenght = len(pubkey_bytes)
if pubkey_lenght > 32: continue

elois · 10 October 2022 13:42

Ce n’est pas un bug, mais un design voulu, il ne sera possible de migrer que les membres de la wot Ğ1v1 qui sont effectivement membres au moment du snapshot, donc qui ont déjà 5 certifications ou plus.

Toutes les identités ayant moins de 5 certifications ne doivent pas être incluses, c’est pourquoi le paramètre genesis_certs_min_received doit être réglé sur 5, afin que duniter-v2s détecte les cas invalides et retourne la bonne erreur.

En bref, ce n’est pas un bug, mais une mauvaise configuration de ta part, car tu a fixé genesis_certs_min_received à zéro.

tuxmain · 10 October 2022 14:52

Pour quoi faire ? Il me semble que DuniterV2S n’empêche pas de réutiliser une adresse ou un pseudo dont l’identité a déjà été révoquée. (d’après mes souvenirs, une recherche dans le code et un test cucumber fait à l’arrache)

poka · 10 October 2022 14:53

Sisi les usernames sont blacklistés, pas les address.
De ce que j’ai pu observer en tout cas.

Maaltir · 10 October 2022 18:09

Moul · 10 October 2022 18:53

Souhaites-tu être admin sur GitLab ? Je trouve que le groupe tools est le plus adapté pour cet outil.

C’est ainsi en base de données. Via BMA (l’api cliente) uniquement la certification active est présentée.

poka · 10 October 2022 20:14

Oui pourquoi pas, merci.

Oui je pense que c’est bien dans le dossier tools.

Je vais filtrer les certifications en double pour laisser les plus récentes.

HugoTrentesaux · 10 October 2022 20:46

Je ne suis pas d’accord avec ça. Exemple concret :

Alice reçoit cinq certifications et devient membre
une année après, Alice certifie Bob
une année après, les certifications reçues Alice expirent et Alice perd le statut de membre
deux mois après on souhaite migrer la Ğ1 (il faut compter la certification de Alice vers Bob)

Donc pour le genesis Ğ1v2 il faut :

créer l’identité Alice (identity index = 1)
créer l’identité Bob (identity index = 2)
ajouter la certification Alice vers Bob (1 → 2) qui expire dans dix mois
retirer l’identité Alice (ses métadonnées et le nom “Alice”).

Autrement dit, les identités non membre ayant moins de 5 certifications actives reçues au moment de la migration (mais ayant émis des certification) doivent être incluses puis exclues.

Il faut filtrer les certifications dont la date d’expiration est antérieure à la date de migration (ne garder que celles toujours actives).

poka · 10 October 2022 22:38

Voilà c’est fait, en effet j’avais un problème avec ma manière de déduire les numéros de blocs, ça me semble mieux ainsi: https://git.duniter.org/tools/py-g1-migrator/-/blob/master/currency_parameters.py#L2-5

Les valeurs des paramètres sont beaucoup plus lisibles et modifiables ainsi.

Déduction du numéro de bloc: lib/utility.py · master · tools / py-g1-migrator · GitLab

Même lien pour le json, @Maaltir il ne devrait plus avoir de soucis de certifications: https://git.duniter.org/tools/py-g1-migrator/-/raw/master/output/gtest.json

poka · 11 October 2022 15:19

J’ai renommé ce repo, déplacé dans le groupe tools, ajouté licence et copyright.

Cela dit, je me demande si je vais pas recréer le dépôt de zero (init commit) car:

J’ai ajouté le build dex qui fait 29 Mo, je peux l’enlever du dépôt et faire en sorte de le télécharger automatiquement depuis quelque part lors de l’exécution de generate_dex_data.sh si le build n’existe pas localement.
Je pourrais déplacer le json final output/gtest.json (5.3Mo) ailleurs, genre dans output/default/ pour ne pas interférer avec les build générés au niveau du git.
Je veux que ce json soit présent simplement pour que chacun puisse y accéder comme Maaltir le fait, sans avoir à cloner ni exécuter quoi que ce soit. Je sais que normalement pour bien faire, ces fichiers générés ne devraient pas être présent dans le repo, mais avez-vous une meilleurs idée ?
Je peux déplacer intput/*json (74Mo) dans input/default/, également pour ne pas interférer avec les build locaux et le git. Je veux aussi que ces json soient présent de manière a pouvoir skip l’étape 1 pour ceux qui n’ont pas de profile Duniter localement.
Je peux fermer ce topic brouillon et en ouvrir un nouveau « Ğ1 data migration » qui présente mieux la chose et puisse ouvrir des discutions plus concrètes sur le format de données genesis v2s.

Je dis tout ça car le .git fait déjà 111Mo inutilement.
Qu’en pensez-vous ?
Je suis preneur d’avis et conseils sur ces sujets de design de repo (tout en prenant en considération mon besoin de garder les json générés par defaut quelque part comme je l’ai expliqué).

Moul · 11 October 2022 15:38

Tu peux utiliser git LFS.

poka · 11 October 2022 16:17

Je ne connaissais pas, ça à l’air super, j’ai essayé un peu, mais le soucis pour moi avec ça est qu’on se retrouve avec des fichiers du type:

$ cat input/blocs.json 
version https://git-lfs.github.com/spec/v1
oid sha256:c9a89582cc2273240c46dbc4439e4d6c2caca44199662ee37e20573dfb3ddf95
size 28742754

et le fait que:

Il ne faut pas oublier que chaque personne qui interagira sur le projet devra suivre la procédure d’installation de Git LFS sur son environnement.

(source)

Donc les json ne seront pas visible normalement via URL gitlab si j’ai bien compris.
Et ça augmente la stack, j’aimerais éviter.

vit · 11 October 2022 16:19

Tu peux générer le JSON avec la CI Gitlab en tant que fichier de Release. La CI de Gitlab se chargerait de télécharger Dex et de générer le JSON dans une Release.

Ou bien le téléverser manuellement sur le wiki Gitlab ou dans les Releases.