Suite à la visio dev du 4 juillet, j’avais trois missions pour participer au lancement de la ĞTest :
publier une archive du réseau Ğ1 (fait pendant la visio)
publier la toile forgeron initiale pour le réseau ĞTest (échec à ménager du temps, elois a fait sans)- aider sur les problèmes de py-g1-migrator (échec à ménager du temps, @moul a pris le relais)
Je n’ai pas réussi à ménager du temps pour remplir mes engagements. Malgré ça, @elois a fourni une grande quantité de travail pour régler un tas de problèmes qui apparaissent au moment où on lance un réseau. Il m’a écrit un SMS hier soir en disant que le réseau ĞTest était lancé, suite à quoi j’ai plein de travail :
- lancer un nœud forgeron pour rejoindre le réseau
- lancer un (ou deux) nœud miroir
- lancer un (ou deux) nœud squid
- publier une version de duniter-panel réglé sur le réseau ĞTest par défaut
- (bonus) importer des données Cesium plus récentes avec le bon préfixe SS58
J’ai donc décidé de poser une journée sans solde pour dégager le temps nécessaire avant l’Agora ML (Agora Monnaie Libre à la Ferme de la Bouzigue du 11 au 14 juillet 2025 - Rencontres Locales Ğ1 - Forum Monnaie Libre).
Dans ce post, je détaille les étapes et le temps que ça me prend pour donner une idée du délai qu’on pourrait viser entre le lancement du bloc zéro de la Ğ1 et le moment où le réseau sera disponible pour les utilisateurs. J’invite les développeurs de clients (Ğecko, Ğinkgo, Cesium²…) à faire de même.
10h
- ajout de l’entrée DNS CNAME pour
gtest.trentesaux.fr - mise à jour de mon
docker-compose.ymlavec l’imageduniter/duniter-v2s-gtest-1000:1000-0.11.0 - récupération des raw specs
https://nodes.pages.duniter.org/-/rust/duniter-v2s/-/jobs/148058/artifacts/release/gtest-raw.json - ajout des bootnodes d’elois
Mon nœud forgeron gtest est lancé avec le fichier suivant :
services:
duniter-smith:
image: duniter/duniter-v2s-gtest-1000:1000-0.11.0
restart: unless-stopped
ports:
# prometheus
- 127.0.0.1:9615:9615
# RPC
- 127.0.0.1:9944:9944
# p2p
- 30333:30333
volumes:
- data-smith:/var/lib/duniter/
- ./chainspecs:/chainspecs
environment:
- DUNITER_CHAIN_NAME=gtest
- DUNITER_NODE_NAME=HugoTrentesaux-smith
- DUNITER_VALIDATOR=true
- DUNITER_PRUNING_PROFILE=light
- DUNITER_PUBLIC_ADDR=/dns/gtest.trentesaux.fr/tcp/30333
- DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333
- DUNITER_CHAIN_NAME=/chainspecs/gtest-raw.json
command:
- "--bootnodes"
- "/dns/gt.elo.tf/tcp/30333/p2p/12D3KooWNUyHfjozVWP2ne5BN7AEwFNzUQvtK6GULxmgBucnYtjG"
- "/dns/gt.elo.tf/tcp/30334/p2p/12D3KooWRugKTSYDo4SKEWhzatSFQVm5vaG74NpZPmVkXE2W8pJU"
volumes:
data-smith:
À ce stade, voici mon nouveau bootnode :
/dns/gtest.trentesaux.fr/tcp/30333/p2p/12D3KooWPm42kinq1qUu9FQdMELWhWyg8vsJCd4tcos6cMuQXxpq
- lancement de mon oracle de distance dans un docker-compose à part (pour le mettre à jour plus facilement si besoin sans risquer d’arrêter mon nœud validateur)
docker-compose.yml de l'oracle
# Duniter distance oracle plugging to smith node
# distance oracle uses same image but another entrypoint
services:
distance-oracle:
image: duniter/duniter-v2s-gtest-1000:1000-0.11.0
entrypoint: docker-distance-entrypoint
environment:
ORACLE_RPC_URL: "ws://duniter-smith:9944"
ORACLE_RESULT_DIR: "/var/lib/duniter/chains/gtest/distance/"
ORACLE_EXECUTION_INTERVAL: "200"
ORACLE_LOG_LEVEL: "info"
volumes:
- data-smith:/var/lib/duniter
networks:
- duniter
# external volume of duniter node to share data for the inherent to read
volumes:
data-smith:
name: duniter-gtest-smith_data-smith
external: true
# external network of duniter node to read data from rpc API
networks:
duniter:
name: duniter-gtest-smith_default
external: true
- génération des certificats letsencrypt sur
gtest.coinduf.eu - arrêt des conteneurs gdev
- démarrage du nœud archive
J’ai dans mes logs ceci :
duniter-archive-1 | 2025-07-10 08:40:05 💔 Verification failed for block 0xca53cc52b4e70f57d958d302288971e9fad1a0ebd7ba3e1ce1081697ec5ab26e received from (12D3KooWNUyHfjozVWP2ne5BN7AEwFNzUQvtK6GULxmgBucnYtjG): "Header 0xca53cc52b4e70f57d958d302288971e9fad1a0ebd7ba3e1ce1081697ec5ab26e rejected: too far in the future"
duniter-archive-1 | 2025-07-10 08:40:05 💔 Error importing block 0x2f8a524b9d583a0660027bc6331988da193f0abde350c3011eb50dfbe4ba7ade: block has an unknown parent
duniter-archive-1 | 2025-07-10 08:40:05 💔 Verification failed for block 0xca53cc52b4e70f57d958d302288971e9fad1a0ebd7ba3e1ce1081697ec5ab26e received from (12D3KooWPm42kinq1qUu9FQdMELWhWyg8vsJCd4tcos6cMuQXxpq): "Header 0xca53cc52b4e70f57d958d302288971e9fad1a0ebd7ba3e1ce1081697ec5ab26e rejected: too far in the future"
duniter-archive-1 | 2025-07-10 08:40:05 💔 Verification failed for block 0xca53cc52b4e70f57d958d302288971e9fad1a0ebd7ba3e1ce1081697ec5ab26e received from (12D3KooWSvvp2zweVBEuaeEGFhjzPRT9ZXZ8wwDoedaHzxVfSXuX): "Header 0xca53cc52b4e70f57d958d302288971e9fad1a0ebd7ba3e1ce1081697ec5ab26e rejected: too far in the future"
duniter-archive-1 | 2025-07-10 08:40:05 💔 Verification failed for block 0xca53cc52b4e70f57d958d302288971e9fad1a0ebd7ba3e1ce1081697ec5ab26e received from (12D3KooWRugKTSYDo4SKEWhzatSFQVm5vaG74NpZPmVkXE2W8pJU): "Header 0xca53cc52b4e70f57d958d302288971e9fad1a0ebd7ba3e1ce1081697ec5ab26e rejected: too far in the future"
qui me rappelle ce sujet : Le nœud forgeron de moul n’est pas à l’heure
À ce stade, j’ai :
un nouveau bootnode :/dns/gtest.coinduf.eu/tcp/30333/p2p/12D3KooWLLadHpZmqFM45HGSahpWcgWbgYUyWswQk6ivXW6C1ByB- un nouveau endpoint rpc :
wss://gtest.coinduf.eu
10h45
Maintenant, l’objectif est de lancer un noeud squid. Ça va demander un peu plus de boulot puisqu’il faut adapter pour le nouveau runtime, utiliser le préfixe SS58 4450, générer les fichiers indexeur avec py-g1-migrator parce qu’ils ne sont pas sur la page de release, je ne sais pas pourquoi, et publier une nouvelle image.
- récupération de
https://files.coinduf.eu/g1v1/backup-1.8.7.tgz - mise à jour de py-g1-migrator en local avec les dernières modifs
- [à ce stade en parallèle je me rends compte que j’ai des problèmes de synchro sur mon nœud miroir qui prend beaucoup de blocs de retard et a les erreurs “too far in the future”]
- démarrage d’un nœud en local pour mettre squid à jour
- le fichier
g1-data.json/genesis.jsoncontient des clés avec le préfixe 42 - mon duniter-panel fonctionne en local avec mon squid local
- publication de la branche
gtest-customsur squid avec quelques patch - publication de l’image
h30x/duniter-squid-gtest:latestcorrespondant à cette branche - démarrage de mon nœud squid public
12h00
Je suis bloqué sur un bug étrange où mon nœud squid coindufeu ne se comporte pas comme mon nœud squid local. Il plante à l’ajout du genesis avec :
TypeError: Cannot set properties of undefined (setting 'eventsCount')
at createFakeEvent (/squid/lib/genesis/genesis.js:56:27)
at saveGenesis (/squid/lib/genesis/genesis.js:360:21)
Ça l’air de venir de giant squid…
Je tente quand même de redémarrer mon nœud archive, il semble qu’il y ait un problème de temps, avec deux heures de décalage entre les nœuds à cause du fuseau horaire.
Je ne sais pas d’où vient ce problème de reproductibilité, je dois débug en prod, ce qui est long.
J’ai perdu du temps là dessus, n’ai pas trop compris d’où venait mon problème, mais pense que ça vient du format des certifications v1. D’ailleurs, je fais des tests de cohérence dans squid et ai obtenu ces logs :
tmp_squid.txt (81.0 KB)
Soit mon test est faux, soit il manque beaucoup de certifications qui seraient censées ne pas avoir expiré et ne sont pourtant pas présentes dans le genesis. Ça fait un sujet à vérifier :
Les certification v1 actives sont-elles bien toutes présentes dans le genesis v2 ? Dans l’historique de certifications squid ?
Cela étant dit, voici mon nœud squid : https://squid.gtest.coinduf.eu/v1/graphql
Ce nœud est sur une branche non finalisée, le calcul de la balance totale est faux.
13h00
Ce point m’a coûté une heure, mais je peux passer à la suite.
- annonce de mes endpoints. J’ajoute ces lignes à mon docker compose archive :
# dans docker compose
- DUNITER_PUBLIC_RPC=wss://gtest.coinduf.eu/
- DUNITER_PUBLIC_SQUID=https://squid.gtest.coinduf.eu/graphql/v1
# pour teste que ça fonctionne
curl -X POST https://gtest.coinduf.eu -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","id":1,"method":"duniter_peerings","params":{}}' | jq
- mise à jour des nœuds par défaut dans duniter panel
Pour l’utiliser, allez d’abord sur la page settings pour faire “erase local storage” (https://duniter--vue-coinduf-eu.ipns.pagu.re/#/settings).
il reste un problème d’intégration de l’extension duniter connect dans duniter panel, le préfixe ss58 devrait être forcé. Pour contourner le problème, il faut cliquer sur “g1” dans la vue g1 (https://duniter--vue-coinduf-eu.ipns.pagu.re/#/g1).
13h35
Il est l’heure d’aller manger. Je publie ce post et continue après la pause.
