État des lieux des différentes chaînes

cgeek · 19 September 2023 17:07

Dans le cadre de “Industrialiser le démarrage d'une nouvelle Ğx”, j’ai dû faire le point sur les différentes chaînes à notre disposition dans le CLI Duniter V2S. Je vous propose un état des lieux (AVANT) puis ce que j’imagine comme fonctionnement (APRES).

Dans la partie APRES, j’introduis une séparation du Genesis Config en deux fichiers :

<currency>-config.json : fichier de configuration qui contient les quelques paramètres spécifiques de la monnaie (montant du DU, fréquence, …, WoT des autorités, session_keys)

g1-data.json : fichier qui contient la WoT Ğ1 + les portefeuilles, commun à toutes les monnaies

Chaîne	Runtime	Genesis (AVANT)	Genesis (APRES)
`dev`	ĞDev	Basé sur le fichier `DUNITER_GENESIS_CONFIG` si fourni, autorité seule Alice. Sinon, auto-généré via 3 paramètres.	Auto-généré via 3 paramètres.
`gdev_local`	ĞDev	Auto-généré via 3 paramètres.	Dérivé de `gdev-config.json`* + `g1-data.json`, autorité seule Alice (ajoutée dynamiquement aux deux WoT).
`gdev_live`	ĞDev	Basé sur le fichier `DUNITER_GENESIS_CONFIG` si fourni, avec les autorités indiquées. Sinon, auto-généré via 3 paramètres.	Dérivé de `gdev-config.json`* + `g1-data.json`, autorités de `gdev.json`.
`gdev`	ĞDev	Embarqué dans le binaire dédié.	Embarqué dans le binaire dédié.
`gdev-benchmark`	ĞDev	Auto-généré.	Auto-généré.
`gtest_dev`	ĞTest	Basé sur le fichier `DUNITER_GENESIS_CONFIG` si fourni, autorité seule Alice. Sinon, auto-généré via 3 paramètres.	Dérivé de `gtest-config.json`* + `g1-data.json`, autorité seule Alice (ajoutée dynamiquement aux deux WoT).
`gtest_live`	ĞTest	Basé sur le fichier `DUNITER_GTEST_GENESIS`.	Dérivé de `gtest-config.json`* + `g1-data.json`, autorités de `g1.json`.
`gtest`	ĞTest	Embarqué dans le binaire dédié.	Embarqué dans le binaire dédié.
`g1`	Ğ1	Non impleménté.	Décliner en `g1_dev`, `g1_live` et `g1` comme pour les chaînes gtest.
`/fichier.json`	Déduit du nom de fichier.	Fourni à l’exécution (via fichier de specs).	Fourni à l’exécution (via fichier de specs).

* : ou du fichier précisé par DUNITER_GENESIS_CONFIG si défini

L’idée est d’avoir une méthode de construction de Genesis commune pour les 3 monnaies, et que seul le fichier de configuration, court et présent dans le code source pour chaque monnaie, soit à spécifier : celui-ci doit être facilement consultable, vérifiable et modifiable.

Les données de la Ğ1 sont quant à elles déposées dans un fichier séparé par py-g1-migrator, afin de ne pas polluer la lecture du fichier de conf précédent.

Egalement, les seules chaînes pour lesquelles les données sont auto-générées sont la dev et gdev-benchmark. J’ai donc supprimé plusieurs cas où l’on avait des toiles auto-générées selon qu’une variable d’environnement était présente, car je ne trouvais pas ça clair.

Pour la chaîne benchmark, à voir s’il ne serait pas plus intéressant d’avoir au contraire les données de la Ğ1.

Voilà, si avez quelques retours à faire je suis preneur. Avant que je ne détricote le code.

HugoTrentesaux · 20 September 2023 07:47

Super chantier de simplifier les chaînes ! J’avoue que ça m’avait causé pas mal de nœuds au cerveau de comprendre comment c’était fichu, notamment les variables d’environnement, je trouvais aussi ça vraiment pas clair. Pour l’instant je m’étais contenté d’ajouter beaucoup de commentaires dans le code et de lisser le comportement pour le runtime gtest.

En voyant ton tableau je me dis qu’on pourrait ajouter une feature de compilation pour activer certaines fonctionnalités sur demande à la compilation.

→ et en regardant le code je m’aperçois que je l’ai déjà fait pour la gtest :

#[cfg(all(feature = "gtest", feature = "embed"))]
"gtest" => Box::new(chain_spec::gtest::ChainSpec::from_json_bytes(
    &include_bytes!("../specs/gtest-raw.json")[..],
)?),

L’idée est que une fois qu’on est content d’un réseau live, on fige les raw chainspecs, et on compile avec la feature embed pour fournir un binaire “clé en main” aux utilisateurs. En résumé, ce que je pense qu’il faudrait faire :

runtime feature	other feature	gdev_live	gdev	gtest_live	gtest
gdev
gdev	embed
gtest
gtest	embed

Cependant, pour ça, il faut s’assurer que le genesis est reproductible (pas de timestamp ou de nombre vraiment aléatoire). Parce que sinon on pourrait démarrer un live network et ne plus être en mesure de produire le même genesis avec la command build-specs.

Question, quand tu écris “Dérivé de gdev-config.json* + g1-data.json”, comment est-ce que tu indiques le chemin de ces fichiers ? Est-ce qu’ils sont fournis à la compilation ou à l’exécution ?

cgeek · 20 September 2023 10:49

Ah oui, j’avais mal lu le code : les raw-specs sont déjà dans le livrable pour les chaînes gdev et gtest, je pensais qu’on les fournissais à l’exécution. J’ai modifié mon tableau en conséquence.

Soit, mais ça signifie que pour une release avec reboot de blockchain il faut re-livrer l’exécutable complet, et peut-être même faire une déclinaison du livrable par blockchain, donc avoir :

duniter-gdev-600, basé sur le Genesis GDev-600 et supportant le Runtime ĞDev 600 en natif
duniter-gdev-601, basé sur le Genesis GDev-600 et supportant le Runtime ĞDev 601 en natif
duniter-gtest-100, basé sur le Genesis GTest-100 et supportant le Runtime ĞTest 100 en natif
…
duniter-gtest-102, basé sur le Genesis GTest-100 et supportant le Runtime ĞTest 102 en natif
duniter-g1-100, basé sur le Genesis G1-100 et supportant le Runtime Ğ1 100 en natif
…

Je suis parti du principe que les chaînes qui requièrent ces fichiers sont exécutées depuis le code source car exploitées par un développeur (donc compilation), tandis qu’un utilisateur exploiterait les chaînes gdev, gtest et g1 (donc exécution).

Cependant je garde la possibilité de préciser gdev-config.json (et équivalents pour gtest et g1) via la variable d’environnement DUNITER_GENESIS_CONFIG notamment pour les besoins de tests end2end et de CI (build des raw-specs à partir d’un dump “frais” de la Ğ1) qui peuvent vouloir préciser un autre fichier.

HugoTrentesaux · 20 September 2023 12:41

On peut les fournir à l’exécution, avec l’option --raw-spec, cf notre discussion Quel genesis une nouvelle version du client doit-il incorporer?. Ça permet de remplacer les raw specs incorporées par une version externe sans changer de binaire.

Oui, l’intérêt d’intégrer le genesis au binaire est qu’on n’a pas à la fournir en dehors. L’inconvénient est que pour changer de genesis, il faut livrer un nouveau binaire (ou utilise --raw-spec). Idem pour les bootnodes.

Ça dépend. Ce n’est pas immédiat d’établir si une version du client est compatible avec un runtime différent. En général ça fonctionne, d’où la possibilité de faire des runtime upgrade sans changer de client, mais si un runtime requiert des api client non présentes dans le client, ça peut ne pas fonctionner. Le versionnage du runtime est indépendant de celui du client. Il me semble que chez purestake, @elois avait travaillé à déterminer si un runtime et un client était compatibles (apparemment il travaille chez moonsong maintenant, d’ailleurs).

Donc en gros, si on reboot une blockchain, on commence par démarrer avec une chaîne “live”, puis on fait build-spec pour passer les raw chainspecs aux autres premiers forgerons. Ces derniers démarrent leur noeud avec un client compatible et l’option --raw-spec pour utiliser les specs du réseau. Enfin, une fois qu’on a un ensemble de bootnodes stables et de confiance, on les inclut dans des client specs et on publie un binaire “tout en un” pour les forgerons qui veulent juste lancer leur nœud mais pas configurer de chaîne custom et de bootnodes.

cgeek · 21 September 2023 10:40

Ce n’est pas ça que je voulais dire, je reprends un de mes exemples :

Cette nomenclature permet de dire que :

le binaire embarque les raw-specs de la ĞDev (c’est la base du raisonnement, si l’on retire les options --chain=gdev, --chain=gtest et --chain=g1 alors tu peux ignorer ce post)
601 permet de dire qu’il s’agit de la ĞDev dans sa série 600, mais n’est pas compatible avec une ĞDev basé sur un Genesis avec Runtime 500 à son lancement
et plus précisément le binaire est compilé avec le Runtime 601, ce qui rend possible l’exécution native du Runtime 601 plutôt que Wasm

HugoTrentesaux · 21 September 2023 12:00

Ok, ce que je n’avais pas compris, c’est la différence entre l’exécution native et wasm du runtime. Je n’ai pas exploré la différence entre les deux, est-ce qu’il y a une histoire de performances par exemple ? Dans ma tête on embarquait toujours le runtime du genesis par simplicité d’utilisation, mais effectivement, on peut aussi embarquer le runtime actuel du réseau et donner le runtime du genesis avec l’option --raw-spec. Mais je ne connais le comportement du substrate dans ce cas, comment fait-il pour choisir le runtime natif plutôt que le wasm ?

cgeek · 21 September 2023 15:55

Oui c’est juste une histoire de performances.

Et dans tous les cas on est obligés d’avoir un Genesis pour démarrer sur une blockchain Substrate et il y a forcément le Runtime initial dedans (c’est imposé par SystemConfig) pour interpréter le bloc#0 et les suivants jusqu’à un éventuel Runtime Upgrade.

Déjà il faut avoir activé l’option (--native-else-wasm par exemple).

Ensuite je ne sais pas trop, mais mes points d’arrêts m’avaient amené à cette instruction dans Substrate. En fait c’est en regardant la version du Runtime natif (ligne juste au-dessus) :

let can_call_with = 
  onchain_version.can_call_with(&self.native_version.runtime_version);

edit : ce n’est pas évident non plus ce block#0, apparemment celui-ci n’est pas importé mais – je pense – est déduit du Genesis. C’est vérifiable en lançant une monnaie locale temporaire sans validateur : on a bien un :

📦 Highest known block at #0

cgeek · 22 September 2023 11:04

C’est bien ça. D’ailleurs les logs au démarrage du client le disent :

🔨 Initializing Genesis block/state (state: 0x0a78…3600, header-hash: 0xc155…d186) 
...
📦 Highest known block at #0
...
💤 Idle (0 peers), best: #0 (0xc155…d186), finalized #0 (0xc155…d186), ⬇ 0 ⬆ 0

“Genesis block/state” : le Genesis désigne aussi bien le block#0 que l’état initial du Storage (au sens où le bloc#0 ne semble rien pouvoir contenir d’autre que l’état initial).

Je me demande d’ailleurs comment réagit la pallet timestamp à ce sujet puisqu’un inherent est attendu à chaque bloc.

edit : c’est tout bête : effectivement le bloc#0 n’est pas importé, c’est plutôt une étape de construction du Storage. Donc il n’est pas régit par les règles habituelles d’exécution du Runtime.

HugoTrentesaux · 22 September 2023 14:43

A post was split to a new topic: Exemple de bug lié à la différence entre runtime wasm et natif

cgeek · 28 September 2023 11:20

A post was split to a new topic: Disparition du paramètre msPeriod (délai entre 2 renouvellements d’adhésion)

cgeek · 1 October 2023 06:48

@HugoTrentesaux : dans les devs V2S que tu as réalisés pour lancer la ĞTest, tu fais des appels à la crate log, par exemple log::warn!.

Je n’arrive pas à faire fonctionner ces instructions sans moi-même ajouter une crate comme env_logger et rajouter une instruction de branchement du logger :

env_logger::try_init().unwrap_or_else(|_| eprintln!("Could not initialize env_logger"));

Mais cette instruction génère d’autres erreurs dans Substrate plus tard.

Comment utilisais-tu ces instructions log::warn! ?

HugoTrentesaux · 2 October 2023 15:03

Voici une ligne de commande que je lançais avec un vieux binaire sur ma machine :

# vieux genesis que je gardais sur ma machine
DUNITER_GTEST_GENESIS=/home/hugo/duniter/specs/gtest_genesis.json \
DUNITER_GTEST_CLIENT_SPEC=/home/hugo/duniter/specs/gtest_client-specs.json \
# vieux binaire que je gardais sur ma machine
duniter-gtest \
--chain gtest_live --tmp --name Hugo_gtest_tmp --no-prometheus --no-telemetry

et j’ai bien les logs.

Je fais donc le test avec un nouveau binaire sur la branche master.

cargo build --features gtest --no-default-features
./target/debug/duniter --chain gtest_live --tmp --name Hugo_gtest_tmp --no-prometheus --no-telemetry

et voici les logs que j’obtiens :

2023-10-02 16:56:59 Duniter    
2023-10-02 16:56:59 ✌️  version 0.3.0-f78c17f902f    
2023-10-02 16:56:59 ❤️  by Axiom-Team Developers <https://axiom-team.fr>, 2021-2023    
2023-10-02 16:56:59 📋 Chain specification: ĞTest    
2023-10-02 16:56:59 🏷  Node name: Hugo_gtest_tmp    
2023-10-02 16:56:59 👤 Role: FULL    
2023-10-02 16:56:59 💾 Database: ParityDb at /tmp/substrate42MVbU/chains/gtest/paritydb/full    
2023-10-02 16:56:59 ⛓  Native runtime: gtest-400 (duniter-gtest-1.tx1.au1)    
2023-10-02 16:56:59 prepared genesis with:
        - 31561 accounts (13050 identities, 18511 simple wallets)
        - 13050 total identities (8326 active, 4724 inactive)
        - 5 smiths
        - 1 initial online authorities
        - 94917 certifications
        - 15 smith certifications
        - 4 members in technical committee    
2023-10-02 16:57:08 🔨 Initializing Genesis block/state (state: 0xd9d9…0978, header-hash: 0x6fe2…ca49)    
2023-10-02 16:57:09 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.    
2023-10-02 16:57:11 👶 Creating empty BABE epoch changes on what appears to be first startup.    
[...]

la section “prepared genesis with:” provient des lignes suivantes :

    // give genesis info
    log::info!(
        "prepared genesis with:

Donc il doit y avoir un problème de configuration de logs. J’imagine qu’il doit y avoir des variables d’environnement pour définir le niveau de log, mais je n’en ai défini aucune de mon côté. Est-ce que tu as un problème sur un certain niveau de logs en particulier ? Ou est-ce que tu n’as aucun log ?

cgeek · 2 October 2023 16:12

Oui : c’est parce que toi tu lances une chaîne alors que de mon côté je teste la commande build-spec.

Si tu l’essaies, à mon avis tu n’auras qu’une seule ligne de logs :

target/debug/duniter build-spec --chain=gdev_dev --raw
2023-10-02 18:09:15.236  INFO main sc_cli::commands::build_spec_cmd: Building chain spec

Mais en y réfléchissant : ça doit être fait exprès pour ne pas polluer la sortie de cette commande vu que celle-ci est censée finir dans un fichier.

HugoTrentesaux · 2 October 2023 18:04

Attention, mon code ne s’exécute que sur le runtime gtest :

./target/debug/duniter build-spec --chain gtest_live > tmp
2023-10-02 20:03:38 Building chain spec    
2023-10-02 20:03:38 prepared genesis with:
        - 31561 accounts (13050 identities, 18511 simple wallets)
        - 13050 total identities (8326 active, 4724 inactive)
        - 5 smiths
        - 1 initial online authorities
        - 94917 certifications
        - 15 smith certifications
        - 4 members in technical committee

cgeek · 2 October 2023 20:23

Je vois pourquoi : c’est parce que ces lignes de log sont produites dans build_genesis() qui elle-même est appelée au sein d’une closure de ChainSpec::from_genesis(). La closure est appelée une fois le logger initialisé, ce qui n’est pas vrai sur ma branche.

Il faut que je déplace mon appel à la génération du Genesis Data dans la closure fournie à ce constructeur.

edit : c’est bon sur ma branche également :

cargo run -- build-spec --chain gdev_dev
2023-10-02 22:49:37 Building chain spec    
2023-10-02 22:49:39 prepared genesis with:
        - 32722 accounts (13469 identities, 19253 simple wallets)
        - 13469 total identities (8059 active, 5410 inactive)
        - 7 smiths
        - 1 initial online authorities
        - 96134 certifications
        - 0 smith certifications
        - 7 members in technical committee    
2023-10-02 22:49:39 currency parameters:
        - existential deposit: 100 ĞD
        - currency decimals: 2
        - membership validity: 73 days
        - certification period: 1 days
        - certification validity duration: 146 days
        - smith membership validity: 73 days
        - smith certification validity: 146 days
        - required certifications: 3
        - smith required certifications: 3
        - max certifications by issuer: 100
        - money growth rate: 4.88%
        - UD creation period: 1 days
        - UD reevaluation period: 7 days
        - distance percent of required referees: 80%
        - distance max depth: 5    
2023-10-02 22:49:39 parameter `membership_period` (73 days) is different from Ğ1's (365.25 days)    
2023-10-02 22:49:39 parameter `cert_period` (1 days) is different from Ğ1's (5 days)    
2023-10-02 22:49:39 parameter `cert_validity_period` (146 days) is different from Ğ1's (730.5 days)    
2023-10-02 22:49:39 parameter `min_cert` value (3) is different from Ğ1 value (5)    
2023-10-02 22:49:39 parameter `ud_reeval_period` value (7 days) is different from Ğ1 value (182.625 days)

cgeek · 19 October 2023 21:41

La branche 125-industrialize-releases-production arrive à maturité, il est temps que je fasse le point sur les changements de chaîne et de Runtime.

Les modifications

Globalement, l’idée est 1 chaîne = 1 comportement, ce qui n’était pas toujours le cas avant.

Chaîne	Runtime	Etat
`dev`	ĞDev	Modifiée : désormais ne fait que générer une toile “random” de 4 membres, 3 smiths et 1 autorité. Son but : faire une toile locale pour du développement.
`gdev_local`	ĞDev	Supprimée car fait doublon avec `dev`.
`gdev_dev`	ĞDev	Nouveauté : c’est la `gdev_live` mais agrémentée d’une autorité forcée “Alice”, qui se voit attribuer les éléments nécessaire à son existence : certifications de membre, certifications de smith, etc.
`gdev_live`	ĞDev	Conservée : c’est la ĞDev “from source”, à compiler, avec les paramètres officiels de la ĞDev (représentés par le fichier `resources/gdev.json`) et les données de la Ğ1 (fichier `g1-data.json`).
`gdev`	ĞDev	Conservée : c’est la ĞDev “from binary”, pré-compilée dans un fichier `specs/gdev-raw.json` lui-même produit à partir d’une `gdev_live` au préalable.
`gtest_dev`	ĞTest	Conservée : même idée que la `gdev_dev` mais pour la ĞTest : c’est une `gtest_live` avec “Alice” comme autorité forcée.
`gtest_live`	ĞTest	Conservée : même idée que `gdev_live`, sauf que le fichier de paramétrage est `resources/gtest.json`. Les données de la Ğ1 sont aussi incorporées via le fichier `g1-data.json`.
`gtest`	ĞTest	Conservée : même idée que `gdev` : c’est la version pré-compilée de la ĞTest, basée sur le fichier `specs/gtest-raw.json`.
`g1`	Ğ1	Conservée : telle quelle pour le moment (non implémentée), mais suivra le même schéma que ĞDev et ĞTest avec son propre fichier de paramétrage.
`/fichier.json`	Déduit du nom de fichier.	Conservée : permet de construire les raw specs à partir d’une spec non-raw, et de modifier uniquement les specs du Client. Voir la documentation Substrate à ce sujet.

J’ai fait l’impasse sur les chaînes de benchmarks, mais celles-ci n’ont pas bougé.

Utilisations

Chaîne	Runtime	Utilisation
`dev`	ĞDev	Tester en local le Runtime avec des comptes maîtrisés (Alice, Bob, …)
`gdev_dev`	ĞDev	Manipuler la vraie ĞDev mais en gardant la maîtrise de l’autorité grâce au compte Alice.
`gdev_live`	ĞDev	La vraie ĞDev, mais réseau non lancé. C’est pour le démarrer.
`gdev`	ĞDev	La vraie ĞDev, mais réseau déjà démarré. C’est pour le rejoindre.
`gtest_dev`	ĞTest	Manipuler la vraie ĞTest mais en gardant la maîtrise de l’autorité grâce au compte Alice.
`gtest_live`	ĞTest	La vraie ĞTest, mais réseau non lancé. C’est pour le démarrer.
`gtest`	ĞTest	La vraie ĞTest, mais réseau déjà démarré. C’est pour le rejoindre.
`g1`	Ğ1	Sera elle aussi découpée en `_dev`, `_live` et sans suffixe.

Options

Pour toutes les chaînes suffixées _dev ou _live, il est possible de redéfinir les fichiers en entrée grâce à des variables d’environnement :

DUNITER_GENESIS_CONFIG : fichier qui définit les paramètres de la monnaie, typiquement le montant du DU, son premier versement, et sa 1ère réévaluation, les smiths initiaux, le comité technique et le compte qui versera les 1,00 Ğ1 initiaux à la Trésorerie.
Pour la ĞDev, ce fichier comporte également les paramètres configurables (qui seront au contraire figés dans le Runtime pour la ĞTest et la Ğ1) comme le nombre de certifications requises pour être membre, etc.
DUNITER_GENESIS_DATA : fichier qui contient les données de toile de confiance initiale et des wallets. Par défaut, c’est celui présent dans resources/g1-data.json, mais dans le cas du lancement d’une nouvelle monnaie (_live) ce fichier est généré à la volée par la CI pour avoir les données les plus fraîches possibles du réseau Ğ1 propulsé par Duniter v1.

Exemple des tests End2End

Les tests Cucumber exploitent un fichier unique (soit default.json, soit wot.json pour le moment) qui agrègent à la fois le contenu de DUNITER_GENESIS_CONFIG et DUNITER_GENESIS_DATA, et lancent un nœud sur la chaîne gdev_dev. De cette façon tous les paramètres et les donnée sont connus d’avance, et l’on dispose notamment des comptes Alice, Bob et cie pour réaliser des manipulations automatisées ainsi que de l’autorité Alice pour créer des blocs.

Voilà, si vous avez des questions ou remarques, n’hésitez pas J’espère que ce travail simplifiera la compréhension de chacun et que nous manipulerons plus facilement les différentes chaînes.

J’ai dû effectuer pas mal de modifications pour en arriver là, nous pourrons aussi en discuter dans la MR!182 dédiée.

HugoTrentesaux · 20 October 2023 10:26

Super, ça me semble bien plus clair comme ça avec l’idée “1 chaîne = 1 comportement”. On pourra reprendre la structure de ce post pour la documentation dans une autre MR.

Le processus de bootstrap était difficile à documenter car rendu peu clair par l’utilisation systématique de docker et les différents comportement possibles pour les chaînes. C’est donc une nette amélioration.

poka · 18 November 2023 19:28

J’essaie d’adapter la config genesis du noeud servant aux tests d’intégrations de Gecko.
Je suis sur l’image debug-sha-44b09061.

Comme Gecko a besoin de gérer des adresses provenant de mnemonic, j’utilise donc des données custom via DUNITER_GENESIS_CONFIG et DUNITER_GENESIS_DATA. J’utilise donc la chaîne gdev_dev pour cela.

Petit détail, le numéro du runtime semble toujours être 0.3.0, il faudra penser à l’incrémenter duniter-v2s-gecko-tests | 2023-11-18 18:54:13 ✌️ version 0.3.0-unknown.

Mon soucis est que quel que soit ce que je tente, le noeud démarre sans erreur mais ne créer pas de block, sans me dire pourquoi.
Si je passe en sealing manual, la methode RPC createBlock n’est pas exposé alors qu’elle devrait.

J’ai compris que Alice avait réservé l’index 6, j’ai donc essayé de l’ajouter dans le groupe clique_smiths et le technical_committee, ainsi que dans la liste des identités avec sa pubkey et son index, sans succès (pas d’erreur mais pas de mieux).

Le fait que désormais ce soit des timestamps au lieu de numéro de block pour les dates dans le genesis rend les configs de tests moins facile à manipuler, moins reproductible (il faut toujours calculer des timestamps cohérents par rapport au moment de lancement du test), mais je comprends l’intérêt pour les migrations de données Ğ1.
Je pense que si le soucis venait de là, les tests d’initialisations devraient le déceler (super d’ailleurs les logs très détaillés au démarrage!).

J’ai aussi essayé de reprendre les mêmes parameters que la config gdev fournit dans le dépôt, même résultat.

Voici:

J’imagine que j’ai dû louper quelque chose

Mes logs:

Résumé

duniter-v2s-gecko-tests  | Node key file '/var/lib/duniter/node.key' exists.
duniter-v2s-gecko-tests  | Node peer ID is '12D3KooWMh72T1jqMBy9qbgRKmP9f8wwQ74kknExQxEDgidZc5A5'.
duniter-v2s-gecko-tests  | Starting duniter with parameters: --name gecko_tests --node-key-file /var/lib/duniter/node.key --rpc-cors all --chain gdev_dev -d /var/lib/duniter --unsafe-rpc-external --unsafe-ws-external
duniter-v2s-gecko-tests  | 2023-11-18 18:54:13 Duniter    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:13 ✌️  version 0.3.0-unknown    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:13 ❤️  by Axiom-Team Developers <https://axiom-team.fr>, 2021-2023    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:13 📋 Chain specification: Development    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:13 🏷  Node name: gecko_tests    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:13 👤 Role: FULL    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:13 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:13 ⛓  Native runtime: gdev-600 (duniter-gdev-1.tx1.au1)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 [Smith] 7 (5FeggKqw2AbnGZF9Y9WPM2QTgzENS3Hit94Ewgmzdg5a3LNa - test1)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 [Smith] 1 (5E4i8vcNjnrDp21Sbnp32WHm2gz8YP3GGFwmdpfg5bHd8Whb - test2)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 [Smith] 2 (5FhTLzXLNBPmtXtDBFECmD7fvKmTtTQDtvBTfVr97tachA1p - test3)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 [Smith] 3 (5DXJ4CusmCg8S1yF6JGVn4fxgk5oFx42WctXqHZ17mykgje5 - test4)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 [Smith] 6 (5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY - Alice)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 [Authority] 1 : offline (5E4i8vcNjnrDp21Sbnp32WHm2gz8YP3GGFwmdpfg5bHd8Whb - test2)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 [Authority] 2 : offline (5FhTLzXLNBPmtXtDBFECmD7fvKmTtTQDtvBTfVr97tachA1p - test3)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 [Authority] 3 : offline (5DXJ4CusmCg8S1yF6JGVn4fxgk5oFx42WctXqHZ17mykgje5 - test4)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 [Authority] 6 : online (5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY - Alice)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 [Authority] 7 : offline (5FeggKqw2AbnGZF9Y9WPM2QTgzENS3Hit94Ewgmzdg5a3LNa - test1)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 prepared genesis with:
duniter-v2s-gecko-tests  |         - 6 accounts (6 identities, 0 simple wallets)
duniter-v2s-gecko-tests  |         - 6 total identities (6 active, 0 inactive)
duniter-v2s-gecko-tests  |         - 5 smiths
duniter-v2s-gecko-tests  |         - 1 initial online authorities
duniter-v2s-gecko-tests  |         - 18 certifications
duniter-v2s-gecko-tests  |         - 20 smith certifications
duniter-v2s-gecko-tests  |         - 4 members in technical committee    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 currency parameters:
duniter-v2s-gecko-tests  |         - existential deposit: 100 ĞD
duniter-v2s-gecko-tests  |         - currency decimals: 2
duniter-v2s-gecko-tests  |         - membership validity: 73 days
duniter-v2s-gecko-tests  |         - certification period: 1 days
duniter-v2s-gecko-tests  |         - certification validity duration: 146 days
duniter-v2s-gecko-tests  |         - smith membership validity: 73 days
duniter-v2s-gecko-tests  |         - smith certification validity: 146 days
duniter-v2s-gecko-tests  |         - required certifications: 3
duniter-v2s-gecko-tests  |         - smith required certifications: 3
duniter-v2s-gecko-tests  |         - max certifications by issuer: 100
duniter-v2s-gecko-tests  |         - money growth rate: 4.88% every 7 days
duniter-v2s-gecko-tests  |         - UD creation period: 1 days
duniter-v2s-gecko-tests  |         - distance percent of required referees: 80%
duniter-v2s-gecko-tests  |         - distance max depth: 5    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 parameter `membership_period` (73 days) is different from Ğ1's (365.25 days)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 parameter `cert_period` (1 days) is different from Ğ1's (5 days)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 parameter `cert_validity_period` (146 days) is different from Ğ1's (730.5 days)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 parameter `min_cert` value (3) is different from Ğ1 value (5)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 parameter `ud_reeval_period` value (7 days) is different from Ğ1 value (182.625 days)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 🔨 Initializing Genesis block/state (state: 0xdce1…d05d, header-hash: 0x47aa…8e5a)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:14 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 👶 Creating empty BABE epoch changes on what appears to be first startup.    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 Using default protocol ID "sup" because none is configured in the chain specs    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 🏷  Local node identity is: 12D3KooWMh72T1jqMBy9qbgRKmP9f8wwQ74kknExQxEDgidZc5A5    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 💻 Operating system: linux    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 💻 CPU architecture: x86_64    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 💻 Target environment: gnu    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 💻 CPU: AMD Ryzen 7 3700X 8-Core Processor    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 💻 CPU cores: 8    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 💻 Memory: 31987MB    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 💻 Kernel: 5.15.0-88-generic    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 💻 Linux distribution: Debian GNU/Linux 11 (bullseye)    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 💻 Virtual machine: no    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 📦 Highest known block at #0    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 〽️ Prometheus exporter started at 127.0.0.1:9615    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 Running JSON-RPC HTTP server: addr=0.0.0.0:9933, allowed origins=["*"]    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 Running JSON-RPC WS server: addr=0.0.0.0:9944, allowed origins=["*"]    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 ***** Duniter has fully started *****    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:15 Accepting new connection 1/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:16 Accepting new connection 2/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:17 Accepting new connection 3/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:17 Accepting new connection 4/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:17 Accepting new connection 5/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:17 Accepting new connection 6/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:18 Accepting new connection 7/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:18 Accepting new connection 8/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:19 Accepting new connection 9/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:19 Accepting new connection 10/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:20 💤 Idle (0 peers), best: #0 (0x47aa…8e5a), finalized #0 (0x47aa…8e5a), ⬇ 0 ⬆ 0    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:20 Accepting new connection 11/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:21 Accepting new connection 12/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:21 Accepting new connection 13/100
duniter-v2s-gecko-tests  | 2023-11-18 18:54:25 💤 Idle (0 peers), best: #0 (0x47aa…8e5a), finalized #0 (0x47aa…8e5a), ⬇ 0 ⬆ 0    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:30 💤 Idle (0 peers), best: #0 (0x47aa…8e5a), finalized #0 (0x47aa…8e5a), ⬇ 0 ⬆ 0    
duniter-v2s-gecko-tests  | 2023-11-18 18:54:35 💤 Idle (0 peers), best: #0 (0x47aa…8e5a), finalized #0 (0x47aa…8e5a), ⬇ 0 ⬆ 0

J’ai essayé de commencer les index à 0 ou 1, d’où la légère incohérence dans cet exemple, mais cela ne semble rien changer.

Bravo en tout cas pour tout ce travail accompli, ça a bien changé depuis la dernière fois que j’y avait mis les pattes.

cgeek · 18 November 2023 19:50

Ton problème se résume au fait qu’avant tu utilisais certainement l’option --dev, qui incluait plusieurs options qu’il te faut désormais rajouter :

--chain=gdev_dev --execution=Native --sealing=manual --force-authoring --rpc-cors=all --alice --tmp --reserved-only --no-mdns

Normalement avec ça ton nœud va se comporter comme Alice et produire des blocs.

A noter qu’il faut que tu executes un purge-chain --chain=gdev_dev avant tout.

poka · 18 November 2023 20:01

En effet, il manquait simplement l’option --alice, et ça tourne!

Auparavant, lorsqu’on définissait un fichier genesis custom sur la chaine dev, l’autorité choisi était la première identité par ordre alphabétique (qui devait donc impérativement être dans le groupe smiths pour que ça fonctionne). 1000i100 était de facto le master de la gdev locale avec data g1…

J’avais essayé l’option --no-mdns sans trop comprendre ce que ça changeait suite à certaines de vos discutions et la MR de Hugo sur le dépôt polkadot-sdk mais ça ne change rien dans mon cas.

Merci