Dans la MR !148, @tuxmain a renommé smiths en smith partout dans le code de Duniter. Cela a pour conséquence de changer le nom des types et des extrinsics, et donc de rendre le développement des outils un peu plus difficiles tant que le réseau ĞDev utilise l’ancien Runtime. Par soucis de simplicité, j’aimerais proposer un runtime upgrade sur la ĞDev pour éviter d’être confronté à ce problème en développant l’indexeur ou Ğcli.
Est-ce que tu vois des trucs qui pourraient bloquer tuxmain ?
1 Like
J’ai ajouté un commit dans Ğcli : TMP NOMERGE revert to old runtime. Il permet de se connecter à la ĞDev dans l’état actuel. Sinon sur ma branche, Ğcli se connecte par défaut à une ĞDev locale avec un Runtime récent.
Je ne vois aucun problème de rétro-compatibilité dans les autres commits depuis le runtime 401, que des correctifs et des benchmarks, plus les offences. C’est OK pour moi.
Une autre solution serait d’annuler mon commit de renommage et de le rejouer juste avant la prochaine version du runtime.
Je m’excuse auprès des devs de clients, mais mieux vaut corriger une faute d’orthographe maintenant et éviter de se demander des milliers de fois s’il y a un “s” aléatoire ou pas, puis de corriger les noms utilisés dans des dizaines de logiciels en prod.
3 Likes
Il y a un problème : les clés du storage ont été modifiées : Réparer les incohérences du storage - #3 by HugoTrentesaux
Donc on va peut-être se retrouver avec des bugs difficiles à comprendre. Par exemple, qui a déjà essayé d’émettre une certification forgeron après le runtime upgrade ?
[edit] et bien ce n’est plus possible parce que les identités forgerons ne sont plus aux bonnes clés :
# quand j'essaye de certifier 1000i100
$ gcli smith cert 1
transaction submitted to the network, waiting 6 seconds...
[src/main.rs:125] e = Runtime(
Module(
ModuleError {
pallet: "SmithCert",
error: "NotEnoughCertReceived",
description: [
"Not enough certifications received",
],
error_data: ModuleErrorData {
pallet_index: 53,
error: [
3,
0,
0,
0,
],
},
},
),
)
Error: Anyhow(Runtime error: Module(ModuleError { pallet: "SmithCert", error: "NotEnoughCertReceived", description: ["Not enough certifications received"], error_data: ModuleErrorData { pallet_index: 53, error: [3, 0, 0, 0] } }))
Rien de pire que d’avoir des données incohérentes 
Fort heureusement ce n’est que la ĞDev.
C’est le genre de choses à couvrir avec des tests unitaires/end2end quand on le voit venir, mais sinon il y a le Golden Testing :
- créer un fichier de sortie avec la version avant modifications (F1)
- créer un fichier de sortie avec la version après modifications (F2)
- comparer F1 et F2.
J’en ai sur Duniter V1 (check_sync_g1.sh), ces tests font partie de la CI mais sont généralement coûteux au point qu’ils ne sont lancés que manuellement. Ces tests dumpent les Index (équivalent du Storage V2S). Pour Duniter V1 je m’arrête après le block 132446, car j’ai pris la Ğ1 comme référence et que ça devenait trop lourd d’aller plus loin. Mais c’était déjà bien représentatif en termes de diversité des données.
Ainsi je pouvais m’assurer que je ne créais pas de régression sur la synchro.
Pour Duniter V2, concrètement les fichiers F1 et F2 sont les dumps du storage, lisibles par un humain et idéalement exploitable par un comparateur comme Meld.
1 Like
A ce sujet : je viens de tomber sur une excellente présentation du fonctionnement interne du Storage Substrate. Je cherchais ça depuis un moment.
Dans cette présentation il y a, je crois, la clé de compréhension sur comment gérer l’état de la blockchain avec les forks ?, point que j’avais résolu dans Duniter V1 mais de façon pas très optimale, et qui contraignait à ne bosser que sur une branche (fork) à la fois. Je n’ai pas encore bien compris si Substrate faisait pareil, mais j’ai l’impression que non. Et j’essaye de comprendre comment ils font 
edit : ou c’est bien ça, Substrate travaille en multi-branches de façon permanente et native : chaque bloc, s’il modifie la moindre valeur, crée un nouvel arbre (Trie) représentant l’ensemble de la base de donnée.
“L’astuce” c’est que l’arbre n’est pas dupliqué, non : c’est le Merkle Tree en filigrane qui gère les embranchements de valeurs. Et donc on ne crée de nouvelles entrées que sur les chemins modifiés. Et dès que des blocs sont finalisés, les forks rendus caducs sont simplement élagués.
Donc cette histoire de Merkle Root fourni à chaque blocs n’est pas juste une lubie sympathique permettant de garantir une bonne synchronisation et rendre facile la vérification d’une transaction pour les clients, non : c’est juste indispensable pour bien forker correctement les valeurs en BDD.
Je suis content d’avoir enfin compris ça
4 Likes
Je ne sais pas si cela est un possible effet de bord.
Mon nœud forgeron est hors-ligne depuis quelques jours alors celui-ci tourne normalement et je n’ai pas vu d’anomalie particulière dans les logs.
@Pini m’avait alerté et avons fait quelques manips ensemble.
Il s’avère que j’ai a priori perdu ma certification forgeron. C’est qu’indique gecko web.
Nous avions tenté un goOnline(), ainsi que d’autres commandes.
L’erreur retournée dans l’extension polkadot du navigateur est consistante : autorithyMembers.notMember.
Les différentes étapes effectuées sont listées dans le salon forgeron matrix.
@HugoTrentesaux as-tu une idée pour rétablir le membership ? Penses-tu cela pourrait être une conséquence du renommage ?
Si on ne corrige pas l’état, on ne peut pas retrouver son identité forgeron et donc on va avoir un effondrement de la toile de confiance forgeron. Je pense que la meilleure stratégie pour éviter de consacrer trop d’efforts à des choses inutiles est de laisser le réseau ĞDev s’effondrer et de monter le prochain réseau ĞTest sur lequel je suis en train de travailler. Je te préviens dès que je lance le réseau (j’espère d’ici deux jours). Nous ferons plus attention à la stabilité de ce réseau.
5 Likes