Python script to generate Ğ1v2 genesis json

En fait j’ai l’impression que pour chaque identité, on liste ses certificateurs (donc on a dû mettre certaines certifs à l’envers dans gdev.json).

Pour vérifier par l’expérience : dans gdev.json il y a 7 certifications sur mon identité, et je suis référencé par 9 identités. En lançant une gdev, l’entrée de storage cert.certs_by_receiver correspondant à mon identité contient 7 identités.

Et je n’avais pas vu que idty_index commençait à 1, donc pour avoir le nom de l’identité pour le debug il faut mettre identities_[*idty_index as usize-1].0. On voit alors que 77ZenAll n’a aucune certification. Soit tu as échangé certifications reçues et émises, soit ta liste d’identités contient des non-membres par manque de certifications. (le idty_index suit l’ordre alphabétique)

3 Likes

Non il n’y a que les membres actuels. Je n’ai pas inversé par inadvertance, c’est que j’étais persuadé que le genesis attendait les certs envoyés, pas reçus (et je pense pas être le seul a penser ça).


J’ai donc régénéré le json avec cette fois ci les certs reçus par identités.

Cette fois ci c’est:
Error: Input("Identity n°206 “Amaralar” has received only 0/1 certifications)")

Dans Cesium je vois pourtant Amaralar membre et ayant 5 certificateurs, mais qui date du 3 octobre (il y a 4 jours) pour la plus vieille.
Mais c’est le cas aussi pour Javilion par exemple dont la première certif date du 17 septembre dernier. Je ne trouve pas de profile vide avec des certifs plus vieille que cette date.

On voit que ça concerne 31 personnes dans ce json qui ont un bloc certs vide.

Je pense donc que ce sont des données de DataJune qui ne sont pas à jours. Je peux filtrer ces profiles sans certs, mais je voudrais m’assurer que cela proviens bien de données DataJune non à jours @HugoTrentesaux

Mais ce qui m’étonne c’est que le username Javilion apparait dans la listes de user DataJune, mais visiblement pas ses certifications (a moins que ce soit un soucis dans mon parsing, j’ai fait cette modif issuer/receiver en 10 minutes).

2 Likes

Donc si je filtre les comptes sans certs, avec genesis_certs_min_received à 1, ça passe bien, mais la blockchain finit toujours avec le même Panic:

Thread 'main' panicked at 'Empty validator set for session 0 in genesis block!', /home/poka/.cargo/git/checkouts/substrate-7b26ec960e31aff5/1647633/frame/session/src/lib.rs:469

Par contre là je ne sais pas du tout ce qu’il manque au genesis pour set les validateurs, pour moi les déclarer et certifer dans le bloc smiths suffit.

Cette erreur n’apparait pas dans le code de Duniter, ça proviens de Substrate directement, donc nécessite de comprendre le mécanisme en jeu derrière.

Je n’ai rien renseigné comme config dans le dossier runtime par exemple, il y a probablement des configs à faire ailleurs que dans le json genesis, si quelqu’un peut m’aiguiller là dessus je veux bien.

Il te faut au moins un smith avec des session keys je pense.

Exemple :

"smiths": {
    "Elois": {
      "certs": ["poka", "cgeek", "vit", "tuxmain", "HugoTrentesaux", "kapis"],
      "session_keys": "0x92743b12d55242276539d7256951cdfda85371caefbd325396da9331011b737d14084d2537f77e786a75b9bcbe351051fad52946ec211724b5e8c93bb8aa7a6f14084d2537f77e786a75b9bcbe351051fad52946ec211724b5e8c93bb8aa7a6f14084d2537f77e786a75b9bcbe351051fad52946ec211724b5e8c93bb8aa7a6f"
    },
    "Elois2": {
      "certs": ["tuxmain", "Elois", "HugoTrentesaux"]
    },

Tu as déjà des indications dans launch-a-live-network.md sur comment générer des session keys, même si je suis en train de compléter dans la MR !114 (ticket #91)

1 Like

Il faut définir des sessions keys pour au moins 1 smith.
Mais c’est quoi que tu essayes de lancer à partir de ce genesis ? Une blockchain locale de dev ou un live network ? Parce que dans le second cas c’est bien plus compliqué il y a plein d’étapes supplémentaires, @HugoTrentesaux est en train de documenter ça suite à notre visio.

Aussi je répète mon précédent post, mais je pense que pour la vraie migration il ne faudra surtout pas vous baser sur GVA, mais extraire directement les données de la bdd de duniter v1 avec un outil comme dex ou autre.

1 Like

Je crois que l’inquiétude de poka est :

Une blockchain local de dev bien sûr, pour commencer.

D’accords, donc pas Dex car la DB Rust sur l’indexation des transactions est peut être corrompu.


Je n’ai jamais eu besoin de créer ou ajouter de sessions keys pour mes blockchains de dev locales.

$ docker run --rm -it --entrypoint duniter duniter/duniter-v2s:debug-latest key generate-session-keys --chain dev --suri "noble stay fury mean poverty delay stadium organ evil east vague can"
grandpa: 5F7qdiJjrCu5xLETrmKJeW4FcKNiHEMWUTrBs4tGRJxWgdF2
babe: 5FLLWRsxdLKfXH9VQH6Yv73hN1oc9KoFkZ5LEHEz1uTR1Qt3
im_online: 5FLLWRsxdLKfXH9VQH6Yv73hN1oc9KoFkZ5LEHEz1uTR1Qt3
authority_discovery: 5FLLWRsxdLKfXH9VQH6Yv73hN1oc9KoFkZ5LEHEz1uTR1Qt3
Session Keys: 0x87189d723e1b2826c243bc433c718ac26ba60526932216a09102a254d54462b890a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d6290a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d6290a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d62
  "smiths": {
    "poka_root": {
      "certs": [
        "elois",
        "HugoTrentesaux",
        "vit",
        "poka",
        "tuxmain"
      ],
      "session_keys": "0x87189d723e1b2826c243bc433c718ac26ba60526932216a09102a254d54462b890a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d6290a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d6290a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d62"
    },
"identities": {
    "poka_root": {
      "balance": 10000,
      "certs": [
        "roodinux",
        "OrAnge",
        "Skarlett",
        "Hera",
        "CiaoBellaCarina",
        "Lol",
        "Ninamaste",
        "poka"
      ],
      "pubkey": "5FLLWRsxdLKfXH9VQH6Yv73hN1oc9KoFkZ5LEHEz1uTR1Qt3"
    },
Error: Input("session_keys field forbidden")

Mais encore une fois je ne cherche pas a faire un live network ici, je vois pas pourquoi j’aurais besoin de sessions_keys.


Je ne comprends pas pourquoi tout fonctionne parfaitement avec ce json: integration_test/duniter/data/gecko_tests.json · master · clients / Ğecko · GitLab

Mais pas avec celui-ci: https://git.duniter.org/pokapow/py-g1-migration/-/raw/master/gtest.json

1 Like

dex permet d’accéder à toutes les DB, y compris à la DB leveldb de référence utilisée par le code en nodejs (à condition que le nœud duniter-v1 soit éteint le temps de l’export), c’est cette DB de référence qu’il faut utiliser.

Car pour les blockchain de dev locales, le code de génération des raw spec assume que seule la 1ère identité est dans le set des autorités au genesis, et que ses sessions keys correspondent aux clés du compte de test //Alice.

Tu as toujours besoin de session keys, c’est juste que dans le cas particulier d’une blockchain locale de dev elles sont automatiquement set avec les credentials du compte de test //Alice et affectées à l’identité n°1.

Il en résulte que l’identité avec le nom le plus haut dans l’ordre alphanumérique doit faire partie des membres forgerons, c’est peut-être ça qui coince dans ton json.

2 Likes

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 ! :champagne:

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.

1 Like

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.

1 Like

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.

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.

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

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

4 Likes

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

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

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.

1 Like

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)

1 Like

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

1 Like