État des lieux des différentes chaînes

[HugoTrentesaux]

@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?. Ç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 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]

@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

[HugoTrentesaux]

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]

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 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]

@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.

[cgeek]

@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]

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]

@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 :

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]

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]

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]

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]

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]

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:

• Mon docker compose
• Mon DUNITER_GENESIS_CONFIG
• Mon DUNITER_GENESIS_DATA

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]

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]

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

[cgeek]

@poka

Petit détail, le numéro du runtime semble toujours être 0.3.0

C’est la version du Client (dans Cargo.toml). Je vais la bumper vers 0.7.0 (pour s’aligner avec le Runtime qui sera en 700).

[vit]

@HugoTrentesaux je désire tester tikka sur un container local comme tu nous l’a montré au RML avec Alice et Bob. Où je pourrais faire le parcours forgeron depuis Tikka, comme tu l’as fait avec gcli.

Quelle est la commande Docker run … pour avoir cette blockchain locale ?

[HugoTrentesaux]

Pendant les RML j’ai utilisé la commande duniter --dev comme je le fais dans plusieurs des vidéos listées ici Les vidéos Duniter V2S.

Le flag --dev correspond à ceci (obtenu avec duniter --help)

      --dev
          Specify the development chain.
          
          This flag sets `--chain=dev`, `--force-authoring`, `--rpc-cors=all`, `--alice`, and `--tmp` flags, unless
          explicitly overridden. It also disables local peer discovery (see --no-mdns and --discover-local)

Donc comme --chain=dev, il utilise “local_testnet_config” comme on peut le voir ici : node/src/command.rs · 514c2fe07f3d45db93629c7a13d1f4e13bc05c55 · nodes / rust / Duniter v2S · GitLab.

Et donc la command docker devrait être quelque chose comme :

docker run duniter/duniter-v2s-gdev

puisque --dev est l’option par défaut quand on ne donne pas de nom de chaîne, cf le docker-entrypoint docker/docker-entrypoint · 514c2fe07f3d45db93629c7a13d1f4e13bc05c55 · nodes / rust / Duniter v2S · GitLab.