### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [19 September 2023 17:07 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/1 "2023-09-19T17:07:34Z")
Dans le cadre de “[Industrialiser le démarrage d'une nouvelle Ğx](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535)”, 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 :
>
> - `-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. 🙂
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [20 September 2023 07:47 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/2 "2023-09-20T07:47:29Z")
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` :
```rust
#[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 ?
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 September 2023 10:49 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/3 "2023-09-20T10:49:29Z")
> [@HugoTrentesaux](#):
>
> 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.
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
- …
> [@HugoTrentesaux](#):
>
> 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 ?
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.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [20 September 2023 12:41 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/4 "2023-09-20T12:41:34Z")
> [@cgeek](#):
>
> je pensais qu’on les fournissais à l’exécution
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?](https://forum.duniter.org/t/quel-genesis-une-nouvelle-version-du-client-doit-il-incorporer/11526). Ça permet de remplacer les raw specs incorporées par une version externe sans changer de binaire.
> [@cgeek](#):
>
> ça signifie que pour une release avec reboot de blockchain il faut re-livrer l’exécutable complet
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.
> [@cgeek](#):
>
> et peut-être même faire une déclinaison du livrable _par blockchain_
Ç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](https://www.linkedin.com/in/elo%C3%AFs-sanchez-358a8427b/?originalSubdomain=fr) 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.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [21 September 2023 10:40 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/5 "2023-09-21T10:40:18Z")
> [@HugoTrentesaux](#):
>
> Ce n’est pas immédiat d’établir si une version du client est compatible avec un runtime différent.
Ce n’est pas ça que je voulais dire, je reprends un de mes exemples :
> [@cgeek](#):
>
> duniter-gdev-601, basé sur le Genesis GDev-600 et supportant le Runtime ĞDev 601 en natif
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
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [21 September 2023 12:00 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/6 "2023-09-21T12:00:28Z")
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 ?
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [21 September 2023 15:55 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/7 "2023-09-21T15:55:39Z")
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.
> [@HugoTrentesaux](#):
>
> Mais je ne connais le comportement du substrate dans ce cas, comment fait-il pour choisir le runtime natif plutôt que le wasm ?
Déjà il faut avoir activé l’option ([`--native-else-wasm`](https://docs.substrate.io/build/build-process/#native-runtime) par exemple).
Ensuite je ne sais pas trop, mais mes points d’arrêts m’avaient amené à [cette instruction dans Substrate](https://github.com/paritytech/substrate/blob/4b6e735f0fab0c50f13e5b7f656512c101cacdeb/client/executor/src/executor.rs#L656). En fait c’est en regardant la version du Runtime natif (ligne juste au-dessus) :
```rust
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
```
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [22 September 2023 11:04 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/8 "2023-09-22T11:04:24Z")
> [@cgeek](#):
>
> 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 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.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [22 September 2023 14:43 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/9 "2023-09-22T14:43:49Z")
A post was split to a new topic: [Exemple de bug lié à la différence entre runtime wasm et natif](https://forum.duniter.org/t/exemple-de-bug-lie-a-la-difference-entre-runtime-wasm-et-natif/11574)
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [28 September 2023 11:20 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/10 "2023-09-28T11:20:28Z")
A post was split to a new topic: [Disparition du paramètre `msPeriod` (délai entre 2 renouvellements d’adhésion)](https://forum.duniter.org/t/disparition-du-parametre-msperiod-delai-entre-2-renouvellements-dadhesion/11589)
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [1 October 2023 06:48 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/11 "2023-10-01T06:48:08Z")
@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 :
```rust
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!` ?
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [2 October 2023 15:03 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/12 "2023-10-02T15:03:58Z")
Voici une ligne de commande que je lançais avec un vieux binaire sur ma machine :
```sh
# 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`.
```sh
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 :
```auto
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 , 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 :
```auto
// 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 ?
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [2 October 2023 16:12 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/13 "2023-10-02T16:12:09Z")
> [@HugoTrentesaux](#):
>
> Donc il doit y avoir un problème de configuration de logs.
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 :
```auto
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.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [2 October 2023 18:04 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/14 "2023-10-02T18:04:53Z")
Attention, mon code ne s’exécute que sur le runtime gtest :
```sh
./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
```
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [2 October 2023 20:23 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/16 "2023-10-02T20:23:31Z")
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 :
```auto
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)
```
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [19 October 2023 21:41 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/17 "2023-10-19T21:41:46Z")
La branche [125-industrialize-releases-production](https://git.duniter.org/nodes/rust/duniter-v2s/-/tree/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](https://docs.substrate.io/reference/how-to-guides/basics/customize-a-chain-specification/). |
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](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/182) dédiée.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [20 October 2023 10:26 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/18 "2023-10-20T10:26:28Z")
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.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [18 November 2023 19:28 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/19 "2023-11-18T19:28:29Z")
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](https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/resources/gdev.json?ref_type=heads#L5-28), même résultat.
Voici:
- [Mon docker compose](https://git.duniter.org/clients/gecko/-/blob/dev/integration_test/duniter/docker-compose.yml?ref_type=heads)
- [Mon DUNITER\_GENESIS\_CONFIG](https://git.duniter.org/clients/gecko/-/blob/dev/integration_test/duniter/data/gecko_config.json?ref_type=heads)
- [Mon DUNITER\_GENESIS\_DATA](https://git.duniter.org/clients/gecko/-/blob/dev/integration_test/duniter/data/gecko_data.json?ref_type=heads)
J’imagine que j’ai dû louper quelque chose 🤔
Mes logs:
> **Résumé**
>
> ```auto
> 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 , 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.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [18 November 2023 19:50 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/20 "2023-11-18T19:50:20Z")
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.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [18 November 2023 20:01 UTC](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562/21 "2023-11-18T20:01:11Z")
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 l[a MR de Hugo sur le dépôt polkadot-sdk](https://github.com/paritytech/polkadot-sdk/pull/2305) mais ça ne change rien dans mon cas.
Merci 🙂
[Next page](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562.md?page=2)