# Industrialiser le démarrage d'une nouvelle Ğx
**URL:** https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535
**Category:** Duniter-v2s
**Tags:** g1, gdev, runtime
**Created:** [2 September 2023 10:29 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535 "2023-09-02T10:29:10Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [27 September 2023 09:51 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/21 "2023-09-27T09:51:35Z")
Voici ce que je note côté py-g1-migrator :
- ajouter la date de versement du premier DU ajouté par tuxmain dans [!178](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/178)
- récupérer l’adresse de la trésorerie pour déplacer la monnaie ignorée
- rendre le préfixe ss58 des addresses paramétrable (42 pour les réseaux de test, [4450](https://forum.duniter.org/t/choix-du-prefixe-ss58-pour-nos-blockchains-substrate/9068) pour la Ğ1)
- s’assurer que la quantité de monnaie dans les comptes correspond à la masse monétaire
- vérifier que la conversion timestamp → nombre de blocs est cohérente
Et à part ça, il faut tenir compte de la sortie des `print` avec un “⚠” pour les incohérences détectées par le migrator.
J’ai notamment fait le tour des sujets qui parlent de ça :
- [Adapter py-g1-migrator pour la migration Ğ1](https://forum.duniter.org/t/adapter-py-g1-migrator-pour-la-migration-g1/11376)
- [What's needed to start a ĞTest network](https://forum.duniter.org/t/whats-needed-to-start-a-gtest-network/11226)
- [Incohérence dans les données? -- certifications expirées](https://forum.duniter.org/t/incoherence-dans-les-donnees-certifications-expirees/11369)
- [V2S: Ğ1 data migration (g1-migrator)](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814)
- [Date de création du DU](https://forum.duniter.org/t/date-de-creation-du-du/11375)
- [Quantité de monnaie sur Duniter](https://forum.duniter.org/t/quantite-de-monnaie-sur-duniter/11373)
- [Total issuance vs monetary mass](https://forum.duniter.org/t/total-issuance-vs-monetary-mass/11360)
- #g1-migrator
Côté Duniter-v2s, je n’ai pas trop documenté à part dans les commentaires du code parce que je m’adaptais à ce que je faisais sortir du migrator. Mais de mémoire et en regardant le code :
- s’assurer que la trésorerie ne crée pas de monnaie au genesis (elle doit être mise à existential deposit minimum, donc si elle est à zéro de la monnaie est ajoutée)
- s’assurer qu’il y tous les check au genesis nécessaires à ne pas avoir d’incohérence de storage
Et donc pour répondre à la question, je dirais que le niveau d’avancement côté `gtest` est assez poussé, il faut être un peu minutieux dans les refactoring et lire les commentaires dans le code. Par contre côté `gdev` il faut pas hésiter à tailler dans le gras, j’ai quasiment pas touché à ce qu’avait fait elois pour éviter de casser les tests qui étaient basés sur cette manière de parser le genesis, mais le but de la factorisation étant de rapprocher les tests des conditions réelles, c’est le moment de casser des trucs.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [27 September 2023 10:56 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/22 "2023-09-27T10:56:12Z")
Merci pour cette réponse très complète. 🙂
Je vais donc plutôt partir du code présent dans le fichier `gtest_genesis`, tout en le faisant rentrer dans le format pivot, puis j’adapterai ce qui tourne autour de la ĞDev. Il y a quand même beaucoup des similitudes, ça devrait bien se passer.
Puis ce sera travail itératif d’incorporation de toutes les règles que tu viens de mentionner, et du transfert des règles qui étaient dans py-g1-migrator vers Duniter afin de centraliser les contrôles auprès du code qui fait foi (le Runtime).
Je ne me rendais pas compte à quel point il restait du travail sur cette partie migration.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [2 October 2023 10:53 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/23 "2023-10-02T10:53:59Z")
Pour suivi : j’ai pratiquement terminé les développements, il me reste des finitions.
Restera ensuite une revue de code à effecuter par tuxmain et/ou Hugo, puis nous pourrons tenter de relancer une ĞDev. A mon avis, tout cela sous 15j.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [5 October 2023 11:13 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/24 "2023-10-05T11:13:34Z")
> [@HugoTrentesaux](#):
>
> ajouter la date de versement du premier DU ajouté par tuxmain dans [!178](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/178)
Traité : est défini dans le fichier de conf de chaque monnaie (`gdev.json`, `gtest.json`).
> [@HugoTrentesaux](#):
>
> récupérer l’adresse de la trésorerie pour déplacer la monnaie ignorée
Je considère que c’est fait, au sens où il n’y a – pour l’instant – aucune monnaie à transférer vers la Trésorerie selon moi. Si cela devait toutefois changer, il suffirait d’adapter la fonction `gen_genesis_data`.
> [@HugoTrentesaux](#):
>
> rendre le préfixe ss58 des addresses paramétrable (42 pour les réseaux de test, [4450](https://forum.duniter.org/t/choix-du-prefixe-ss58-pour-nos-blockchains-substrate/9068) pour la Ğ1)
N’est plus nécessaire : les comptes Ğ1v1 sont importées bruts (clé publique Ed25519) car Substrate ne fait qu’extraire les clés publiques et ne contrôle pas les adresses pour le Genesis.
> [@HugoTrentesaux](#):
>
> - s’assurer que la quantité de monnaie dans les comptes correspond à la masse monétaire
Fait, [on voit que ce n’est pas le cas](https://forum.duniter.org/t/reprise-g1-monnaie-manquante/11601). Reste à voir d’où provient ce delta.
> [@HugoTrentesaux](#):
>
> vérifier que la conversion timestamp → nombre de blocs est cohérente
La conversion se fait côté Substrate, et [un test couvre ce cas de figure](https://git.duniter.org/nodes/rust/duniter-v2s/blob/1b22dd7f75c370285b4bb6f7768a19301e80cc00/node/src/chain_spec/gen_genesis_data.rs#L1187-1187).
> [@HugoTrentesaux](#):
>
> Et à part ça, il faut tenir compte de la sortie des `print` avec un “⚠” pour les incohérences détectées par le migrator.
Les seules sorties qui méritent encore de l’attention selon moi sont :
```auto
⚠️ Pseudo1 → Llorens cert expired between export and start
⚠️ Pseudo2 has received only 1 certs, disabling it
```
Je vais voir pour les déplacer côté Duniter.
> [@HugoTrentesaux](#):
>
> J’ai notamment fait le tour des sujets qui parlent de ça
OK.
* * *
Par conséquent, reste à faire :
Ne pas filtrer les certifications ou identités côté py-g1-migrator mais côté Duniter
s’assurer que la trésorerie ne crée pas de monnaie au genesis (elle doit être mise à existential deposit minimum, donc si elle est à zéro de la monnaie est ajoutée)
s’assurer qu’il y tous les check au genesis nécessaires à ne pas avoir d’incohérence de storage
[Adapter py-g1-migrator pour la migration Ğ1](https://forum.duniter.org/t/adapter-py-g1-migrator-pour-la-migration-g1/11376)
[What’s needed to start a ĞTest network](https://forum.duniter.org/t/whats-needed-to-start-a-gtest-network/11226)
[Incohérence dans les données? – certifications expirées](https://forum.duniter.org/t/incoherence-dans-les-donnees-certifications-expirees/11369)
[V2S: Ğ1 data migration (g1-migrator)](https://forum.duniter.org/t/v2s-g1-data-migration-g1-migrator/9814)
[Date de création du DU](https://forum.duniter.org/t/date-de-creation-du-du/11375)
[Quantité de monnaie sur Duniter](https://forum.duniter.org/t/quantite-de-monnaie-sur-duniter/11373) / [Total issuance vs monetary mass](https://forum.duniter.org/t/total-issuance-vs-monetary-mass/11360)
#g1-migrator ==\> seulement le sujet [V2S: smooth gradual migration (clients and indexers side)](https://forum.duniter.org/t/v2s-smooth-gradual-migration-clients-and-indexers-side/9827)
Pas sûr que je traite tout dans la même MR, nous verrons.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [6 October 2023 20:49 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/25 "2023-10-06T20:49:24Z")
Il me reste deux sujets :
- la masse monétaire “manquante” : pas nécessaire pour redémarrer la ĞDev, et sujet de désaccords (voir [[Reprise Ğ1] Monnaie manquante - #13 by cgeek](https://forum.duniter.org/t/reprise-g1-monnaie-manquante/11601/13)), **mais surtout non bloquant pour la ĞDev 600**
- la création d’un Genesis pour l’indexeur de @ManUtopiK à partir du GenesisData : là-dessus je ne sais pas bien ce qui est attendu, en tout cas l’emplacement pour réaliser le mapping entre GenesisData et le json à fournir à l’indexeur [se trouve ici](https://git.duniter.org/nodes/rust/duniter-v2s/blob/4b59d75ee0dfa1e9d278ac0cd724692055a1f03a/node/src/chain_spec/gen_genesis_data.rs#L1251-1251). Voici un exemple d’export résultat :
[indexer.json.zip](https://forum.duniter.org/uploads/short-url/e7dcGdgwt50teKMz6OpZjqlwmeP.zip) (3,8 Mo) ce fichier peut être re-généré une fois la ĞDev lancée **donc là aussi non bloquant pour la ĞDev 600**
Bref pour moi la tâche arrive à sa fin, je vais peaufiner les 2-3 TODOs que j’ai laissé dans le code, nettoyer le fichier `.gitlab-ci.yml` puis tester tout cela de bout en bout, créer une release et lancer une ĞDev locale.
Vous pouvez déjà commencer à inspecter la [MR!182](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/182) si vous le souhaitez.
---
### Author:  [@ManUtopiK](https://forum.duniter.org/u/ManUtopiK)
#### Post date: [7 October 2023 00:33 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/26 "2023-10-07T00:33:10Z")
Pour la création d’un Genesis pour l’indexer, il faut extraire de la v1 toutes les transactions avec le message, toutes les certifications des membres… et je me souviens plus. Il faut que je regarde ce qu’avait fait @poka.
J’ai regardé dans le indexer.json.zip, il n’y a pas les certifications ?
Sinon, merci à toi ! Génial de voir que ça avance 🙂
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [8 October 2023 07:50 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/27 "2023-10-08T07:50:14Z")
A regarder py-g1-migrator, je dirais que l’indexer mange deux fichiers :
- `gdev.json` : un fichier de Genesis
- `history.json` : un fichier d’historique des transactions
> [@ManUtopiK](#):
>
> J’ai regardé dans le indexer.json.zip, il n’y a pas les certifications ?
Si dans le champ `certs_by_receiver`, qui associe à l’index du receveur une map issuer → dateExpiration. Mais on peut facilement lui donner une autre tête, en mettant les pseudonymes, les clés publiques ou encore les adresses. A toi de me dire 🙂
---
### Author:  [@ManUtopiK](https://forum.duniter.org/u/ManUtopiK)
#### Post date: [8 October 2023 09:20 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/28 "2023-10-08T09:20:37Z")
Ah, je n’avais pas vu le champ !
Oui, l’indexer a besoin de ces 2 fichiers. Les derniers en date que l’on a utilisés sont là :
> **[resources · master · nodes / duniter-indexer · GitLab](https://git.duniter.org/nodes/duniter-indexer/-/tree/master/resources)**
>
> Indexer for Duniter-v2s with Fastify (Node.js) and Hasura (GraphQL on PostgreSQL database)
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [8 October 2023 12:07 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/29 "2023-10-08T12:07:06Z")
OK, je vais reprendre leur format dans ce cas. Si je mets tout dans un seul fichier `indexer-gdev.json` par exemple, ça te va aussi ?
---
### Author:  [@ManUtopiK](https://forum.duniter.org/u/ManUtopiK)
#### Post date: [8 October 2023 13:08 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/30 "2023-10-08T13:08:09Z")
Oui, carrément ! Je m’adapte 🙂
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [10 October 2023 09:57 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/31 "2023-10-10T09:57:55Z")
> [@cgeek](#):
>
> N’est plus nécessaire : les comptes Ğ1v1 sont importées bruts (clé publique Ed25519) car Substrate ne fait qu’extraire les clés publiques et ne contrôle pas les adresses pour le Genesis.
Petit inconvénient de forcer ceci dans le format du genesis : on ne bénéficie plus de la checksum intégrée à l’adresse. Embêtant pour les fichiers de test dans lesquels c’est pratique de mettre les adresses plutôt que les pubkeys “nues”.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [10 October 2023 10:39 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/32 "2023-10-10T10:39:12Z")
Tu parles des fichiers Cucumber ?
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [10 October 2023 10:39 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/33 "2023-10-10T10:39:48Z")
Oui, par exemple, ou quand on veut un fichier custom de dev local avec Alice Bob et compagnie.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [10 October 2023 10:42 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/34 "2023-10-10T10:42:32Z")
Dans ce cas on peut laisser les deux champs : `pubkey` et `address`, les deux étant optionnels et j’ajoute un contrôle dans `gen_genesis_data` pour qu’un seul des deux champ soit renseigné.
Je vais voir, j’ai encore des vérifications à faire avant de me repencher sur ce genre de cas.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [10 October 2023 20:44 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/35 "2023-10-10T20:44:21Z")
Voilà une nouvelle version, qui ressemble beaucoup plus à l’ancien `gdev.json` avec une nouvelle entrée `"transactions_history"` : [https://dl.cgeek.fr/indexer.json.zip](https://dl.cgeek.fr/indexer.json.zip)
Le fichier JSON fait 85Mo 😁
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [12 November 2023 08:24 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/36 "2023-11-12T08:24:06Z")
4 posts were merged into an existing topic: [Tests E2E qui ne sont pas correctement joués sur la CI](https://forum.duniter.org/t/tests-e2e-qui-ne-sont-pas-correctement-joues-sur-la-ci/11692/7)
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [12 November 2023 08:23 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/40 "2023-11-12T08:23:30Z")
6 posts were split to a new topic: [Tests E2E qui ne sont pas correctement joués sur la CI](https://forum.duniter.org/t/tests-e2e-qui-ne-sont-pas-correctement-joues-sur-la-ci/11692)
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [14 November 2023 12:35 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/41 "2023-11-14T12:35:51Z")
La branche a été mergée. Petite présentation du nouveau processus de livraison que nous utiliserons pour [prochainement relancer la ĞDev (700)](https://forum.duniter.org/t/gdev-runtime-700/11684).
# Créer une release
## Création de la branche `release/runtime-`
La création se réalise en créant une branche depuis master `release/runtime-` où `` est la version du Runtime. Exemple : `release/runtime-700`.
## Job pour créer le tag et la page de release
Une fois la branche poussée, GitLab CI crée un pipeline comme le suivant qui s’affiche et s’exécute jusqu’à l’étape bloquante `create_release` :
On voit ici tous les jobs impliqués, leurs liens de dépendance et ceux qui nécessitent une action manuelle symbolisée par l’icône ▶.
Les dépendances sont matérialisées par les lignes grises (ou bleues au survol d’un job). Dans la capture ci-dessus je survole `create_release`.
## Le contenu de la page de release
Une fois lancé le job `create_release`, la page de release _et le tag_ (ici `runtime-700`) sont créés.
La release contient les informations suivantes.
### Assets
Ce sont les livrables par défaut de toute release, même si certains ne seront pas exploités.
#### Les Runtime
Quoi qu’il arrive, les fichiers de Runtime seront exploités : soit pour faire un Runtime upgrade, soit pour démarrer un nouveau réseau.
- `gdev_runtime.compact.compressed.wasm` : le Runtime ĞDev
- `gtest_runtime.compact.compressed.wasm` : le Runtime ĞTest
#### Les Spec
Ces fichiers ne seront utilisés que si l’on souhaite démarrer ou rebooter une monnaie. Néanmoins, en l’état actuel du développement de Duniter V2, c’est une opération que nous sommes susceptible de réaliser fréquemment donc pour l’instant ces livrables seront produits à chaque fois.
##### En entrée
Ces fichiers sont présents dans la page de Release uniquement par soucis de transparence et de vérification. Seuls les fichiers “En sortie” seront directement exploités.
- `gdev.json`: le fichier de configuration du Genesis pour la spec du réseau ĞDev
- `gtest.json`: le fichier de configuration du Genesis pour la spec du réseau ĞTest
- `gdev_clients-specs.json`: le fichier de configuration du Client pour la spec du réseau ĞDev
- `gtest_clients-specs.json`: le fichier de configuration du Client pour la spec du réseau ĞTest
- `g1-data.json` : le fichier de migration des données de la Ğ1 intégrées à la spécification des réseaux ĞDev et ĞTest
##### En sortie
Les fichiers de specs :
- `gdev-raw.json` : la spécification du réseau ĞDev, résultante de `gdev.json`, `g1-data.json` et `gdev_client-specs.json`
- `gtest-raw.json` : la spécification du réseau ĞTest, résultante de `gtest.json`, `g1-data.json` et `gtest_client-specs.json`
### Runtimes
Les détails des deux Runtimes (bientôt trois avec la Ğ1) produits, un pour chaque réseau :
### Les changements et tickets impliqués dans cette release
# Créer ou rebooter un réseau (une monnaie)
Si le Runtime doit servir à rebooter un réseau (par exemple redémarrer la ĞDev), alors il y a deux étapes supplémentaires à réaliser.
## Commiter les chain specs
C’est une pratique courante avec Substrate : [publier les chain specs avec le code source du projet](https://docs.substrate.io/reference/how-to-guides/basics/customize-a-chain-specification/#publish-the-raw-chain-specification).
Une commande `xtask` a été créé pour l’occasion. Ici, pour mettre à jours les chain specs du `runtime-700`, _à lancer depuis la branche de release_ :
```
cargo xtask update-raw-specs runtime-700
```
Cette commande va télécharger les chain specs publiées dans la page de release si celles-ci existent :
- gdev-raw.json
- gtest-raw.json
- g1-raw.json
Et les pousse dans le répertoire `node/specs/`.
Il suffit alors de commiter ces fichiers et de les pousser depuis la branche de release.
## Builder les images Docker
Créer ou rebooter une monnaie implique de relivrer le Client, puisque celui-ci se base sur les chain specs pour _authentifier_ la blockchain à laquelle celui-ci va se connecter.
Une fois l’étape précédente réalisée (commiter les chain specs), la CI propose alors deux jobs permettant de builder puis publier les images Docker idoines :
- `gdev_docker_release_build` : pour **builder** l’image Docker du Client **ĞDev**
- `gtest_docker_release_build` : pour **builder** l’image Docker du Client **ĞTest**
- `gdev_docker_release_deploy` : pour **publier** l’image Docker du Client **ĞDev**
- `gtest_docker_release_deploy` : pour **publier** l’image Docker du Client **ĞDev**
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [19 November 2023 18:44 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/42 "2023-11-19T18:44:48Z")
Petit retour d’expérience suite au [redémarrage de la ĞDev réalisé aujourd’hui](https://forum.duniter.org/t/gdev-runtime-700/11684/11), notamment pour essayer de projeter le temps d’indisponibilité lors de la migration de la Ğ1 sur Duniter V2S.
# Détail de la procédure
Je reprends point par point les étapes que j’ai dû exécuter pour rebooter la ĞDev de zéro avec les données actuelles de la Ğ1.
## 1. Dumper la Ğ1 avec py-g1-migrator
🕐 _Environ 1 minute._
Ce processus est assez rapide, mais manuel. Je lance un script chez moi qui copie à chaud les fichiers suivants de Duniter v1 :
- Répertoire `data/`
- Répertoire `g1/`
- Fichier `txs.db`
Le tout est zippé et mis à disposition sur [https://dl.cgeek.fr/public/backup-g1-duniter-1.8.7.tgz](https://dl.cgeek.fr/public/backup-g1-duniter-1.8.7.tgz)
## 2. Créer la release
_🕐 Environ [11 minutes](https://git.duniter.org/nodes/rust/duniter-v2s/-/pipelines/34325)._
Consiste à :
- pusher le branche de release (ex. `release/runtime-700` ici)
- actionner le bouton sur le job `create_release` lorsque celui-ci devient disponible
## 3. Mettre à jour les raw-specs
🕐 _Environ 1 minute._
Consiste à :
- lancer la commande `cargo xtask update-raw-specs runtime-700`
- commiter et pusher les fichiers de specs qui ont été mis à jour par la commande précédente
## 4. Créer l’image Docker du client
[🕐 _Environ 11 minutes._](https://git.duniter.org/nodes/rust/duniter-v2s/-/jobs/120076)
Consiste à :
- actionner le bouton sur le job `g1_docker_deploy` lorsque celui-ci devient disponible
- attendre la fin du build
## 5. Lancer le réseau
_🕐 1 minute_
Consiste à :
- lancer le conteneur Docker
> Suppose d’avoir préparé en amont la clé du nœud et les clés de session compatibles avec la spec Ğ1.
# Conclusion
⏩ 🕐 Cela fait donc **un total de ~25 minutes de blocage de la Ğ1 en l’état actuel du processus**. Il est sûrement possible de descendre aux environs de 10 minutes en optimisant.
> ⚠ Il faut bien noter que ces temps s’obtiennent en ayant préparé les étapes 2 et 5.
Cela dit, je ne suis pas sûr qu’il soit souhaitable de trop mettre d’énergie dans des optimisations : 25 minutes me semble déjà tout à fait acceptable. Je vous laisse juger.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [20 November 2023 11:25 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/43 "2023-11-20T11:25:21Z")
C’est super que tout ce processus prenne “si peu” de temps ! Et on peut tout à fait lancer un réseau en deux minutes environ :
- dumper la Ğ1 comme tu fais (1 minute)
- lancer `build-spec --raw` avec un binaire pré-compilé (\< 10 secondes)
- lancer duniter avec `--chain ./gdev-raw.json` (\< 10 secondes)
Voilà, le réseau est lancé ! Les étapes suivantes vont permettre à d’autres forgerons de rejoindre mais n’ont pas besoin d’être réalisées avant le lancement du réseau.
[Previous page](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535.md?page=1)
[Next page](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535.md?page=3)