Duniter-gtest v2.0.5 (bootnodes GTest et configuration du hard fork GRANDPA)

Nodes Duniter-v2s
1

Une nouvelle version de Duniter est disponible pour la GTest. Elle ajoute des bootnodes gtest et corrige plusieurs bugs survenus suite au forçage de finalité effectué par le comité technique sur la GTest il y a 10 jours :

  • Un nouveau nœud pouvait parfois bannir tous ses pairs et perdre le réseau en rejetant des justifications GRANDPA qu’il considérait invalides. Cela est dû au fait que la chaîne de preuve GRANDPA est cassée lorsque l’on force la finalité avec le root call grandpa.noteStalled. Pour la réparer, il faut configurer un hard fork GRANDPA, hardcodé dans le binaire.

  • La warp sync ne fonctionnait plus depuis le hard fork de finalité. Le Polkadot SDK ne supporte pas la warp sync sur les réseaux ayant subi un hard fork de finalité GRANDPA. Je pense que cela n’a jamais été corrigé, car Polkadot n’a jamais eu de hard fork (seuls Kusama et certains réseaux de test en ont eu), et les opérateurs de nœuds sur Kusama acceptent de mettre plusieurs jours à synchroniser (voire des semaines). Ce n’est pas acceptable pour nous si l’on veut supporter du matériel peu puissant sur le long terme. J’ai donc patché le Polkadot SDK pour supporter partiellement la warp sync sur les réseaux avec hard fork GRANDPA. Je n’ai patché qu’un des deux modes de la warp sync, mais c’est le mode par défaut dans Duniter v2.0.5, donc si vous utilisez --sync warp, cela fonctionnera.

Nouvelle image Docker : duniter/duniter-gtest-1000:1100-2.0.5

Page de release GitLab : gtest-1000-2.0.5 · nodes / rust / Duniter v2S · GitLab

Release notes

  • Fix warp sync: always serve /sync/warp sub protocol (!395)
  • Gtest bootnodes (!393)
  • Resolve “Warp sync: use WithTarget from trusted checkpoint” (!392)
  • Fix gtest GRANDPA state and sync: configure GRANDPA hard forks and patch polkadot-sdk warp sync (!397)
5 Likes
2

Je suis perdu dans la nomenclature des images Docker. Pourquoi duniter/duniter-gtest-1000 et pas duniter/duniter-gtest-1100 ?

3

Parce que le numéro dans la partie image (pas le tag) est censé représenter la version du runtime Genesis. Le test gtest a été lancé avec le runtime 1000. Il y a eu une erreur de nommage de l’image initiale, qui aurait dû s’appeler gtest-1000. Je ne fais que corriger cette erreur.

1 Like
4

OK, donc pour éviter toute ambiguïté ce serait peut-être bien de dépublier duniter/duniter-v2s-gtest-1100, non ?

2 Likes
5

J’ai essayé de démarrer un noeud Gtest from scratch. J’ai le même docker-compose.yml que pour la g1, avec adaptation des variables et nom d’image pour la Gtest.

Le noeud ne démarre pas et la log affiche :

Generating node key file '/var/lib/duniter/node.key'...

thread 'main' panicked at node/src/command.rs:244:26:
unknown runtime
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
Node peer ID is ''.
Starting duniter with parameters: --name pini-gtest-mirror --node-key-file /var/lib/duniter/node.key --public-addr /dns/gtest.pini.fr/tcp/443/wss --rpc-cors all --no-prometheus --state-pruning archive --blocks-pruning archive --chain g1 -d /var/lib/duniter --unsafe-rpc-external

Il semblerait que ce soit la génération du fichier node.key qui échoue.

6

D’après tes log tu lance avec --chain g1, tu à oublié de modifier DUNITER_CHAIN_NAME

1 Like
7

Oups. Bien vu !

8

Heu, je viens de me faire avoir en mettant à jour vers l’image
image: duniter/duniter-v2s-gtest-1000:latest

J’avais juste remplacé “gtest-1100” par “gtest-1000” et je me suis retrouvé en version 1.11.1 dans la télémétrie :smiley:

Du coup, comme le mentionne @Pini

Ce serais bien de dépublier toutes les images obsolètes

  • duniter/duniter-v2s-gtest-1100:*
  • duniter/duniter-v2s-gtest-1000:*
  • ? duniter/duniter-v2s-test:*

Et probablement pas mal d’autres qui pourraient être retirées également

1 Like
9

Je n’ai pas les droits pour faire ça. Les images sont publiées via la CI, et je ne vais pas développer une CI spécifique pour ça; c’est beaucoup trop chronophage. Il faudrait que quelqu’un qui a les droits puisse dé-publier ces images directement. @poka @Moul Est-ce que vous avez les droits pour dé-publier ces images ?

1 Like
10

Mon nœud gtest rpc est à jour.

1 Like
11

Je ne sais pas exactement quoi supprimer.

Tu peux trouver les accès ici ou dans les variables CI/CD du dépôt.

12

Instances mises à jour.

13

Je viens de relancer mon nœud RPC qui s’est arrêté le 28 mars, avec ces logs :

2026-03-26 11:26:34 ⚙️  Syncing  0.0 bps, target=#2386963 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 3.7kiB/s ⬆ 1.4kiB/s    
2026-03-26 11:27:51 ⚙️  Syncing  0.0 bps, target=#2386976 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 5.6kiB/s ⬆ 1.5kiB/s    
2026-03-26 11:29:23 ⚙️  Syncing  0.0 bps, target=#2386991 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 4.5kiB/s ⬆ 1.7kiB/s    
2026-03-26 11:31:23 ⚙️  Syncing  0.0 bps, target=#2387011 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 4.8kiB/s ⬆ 1.0kiB/s    
2026-03-26 11:33:58 ❌ Error while dialing /dns/telemetry.polkadot.io/tcp/443/x-parity-wss/%2Fsubmit%2F: Custom { kind: Other, error: Timeout }    
2026-03-26 11:33:58 ⚙️  Syncing  0.0 bps, target=#2387037 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 4.6kiB/s ⬆ 1.1kiB/s    
2026-03-26 11:37:27 ⚙️  Syncing  0.0 bps, target=#2387072 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 3.9kiB/s ⬆ 1.4kiB/s    
2026-03-26 11:42:27 ❌ Error while dialing /dns/telemetry.polkadot.io/tcp/443/x-parity-wss/%2Fsubmit%2F: Custom { kind: Other, error: Timeout }    
2026-03-26 11:42:27 ⚙️  Syncing  0.0 bps, target=#2387122 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 4.0kiB/s ⬆ 1.2kiB/s    
2026-03-26 11:50:03 ⚙️  Syncing  0.0 bps, target=#2387198 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 3.6kiB/s ⬆ 1.2kiB/s    
2026-03-26 12:02:57 ❌ Error while dialing /dns/telemetry.polkadot.io/tcp/443/x-parity-wss/%2Fsubmit%2F: Custom { kind: Other, error: Timeout }    
2026-03-26 12:02:57 ⚙️  Syncing  0.0 bps, target=#2387327 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 3.3kiB/s ⬆ 1.0kiB/s    
2026-03-26 12:10:32 The number of unprocessed messages in channel `mpsc_chain_sync` exceeded 100000.
The channel was created at:
   0: sc_utils::mpsc::tracing_unbounded
   1: sc_network_sync::engine::SyncingEngine<B,Client>::new
   2: sc_service::builder::build_network
   3: duniter::service::new_full
   4: tokio::runtime::park::CachedParkThread::block_on
   5: tokio::runtime::runtime::Runtime::block_on
   6: sc_cli::runner::Runner<C>::run_node_until_exit
   7: duniter::command::run
   8: duniter::main
   9: std::sys::backtrace::__rust_begin_short_backtrace
  10: std::rt::lang_start::{{closure}}
  11: std::rt::lang_start_internal
  12: main
  13: __libc_start_main
  14: _start


					 Last message was sent from:
   0: core::result::Result<T,E>::inspect
   1: <S as futures_core::stream::TryStream>::try_poll_next
   2: <finality_grandpa::voter::Voter<H,N,E,GlobalIn,GlobalOut> as core::future::future::Future>::poll
   3: <sc_consensus_grandpa::VoterWork<B,Block,C,N,S,SC,VR> as core::future::future::Future>::poll
   4: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
   5: <futures_util::future::select::Select<A,B> as core::future::future::Future>::poll
   6: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
   7: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
   8: <sc_service::task_manager::prometheus_future::PrometheusFuture<T> as core::future::future::Future>::poll
   9: <futures_util::future::select::Select<A,B> as core::future::future::Future>::poll
  10: <tracing_futures::Instrumented<T> as core::future::future::Future>::poll
  11: tokio::runtime::park::CachedParkThread::block_on
  12: tokio::runtime::context::runtime::enter_runtime
  13: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
  14: tokio::runtime::task::core::Core<T,S>::poll
  15: tokio::runtime::task::harness::Harness<T,S>::poll
  16: tokio::runtime::blocking::pool::Inner::run
  17: std::sys::backtrace::__rust_begin_short_backtrace
  18: core::ops::function::FnOnce::call_once{{vtable.shim}}
  19: std::sys::pal::unix::thread::Thread::new::thread_start
  20: start_thread
  21: clone
    
2026-03-26 12:28:42 ⚙️  Syncing  0.0 bps, target=#2387584 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 2.8kiB/s ⬆ 0.8kiB/s    
2026-03-26 13:35:33 ❌ Error while dialing /dns/telemetry.polkadot.io/tcp/443/x-parity-wss/%2Fsubmit%2F: Custom { kind: Other, error: Timeout }    
2026-03-26 13:35:33 ⚙️  Syncing  0.0 bps, target=#2388253 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 2.2kiB/s ⬆ 0.7kiB/s    
2026-03-26 18:35:10 ⚙️  Syncing  0.0 bps, target=#2391229 (10 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 1.2kiB/s ⬆ 0.4kiB/s    
2026-03-28 08:08:34 ❌ Error while dialing /dns/telemetry.polkadot.io/tcp/443/x-parity-wss/%2Fsubmit%2F: Custom { kind: Other, error: Timeout }    
2026-03-28 08:08:34 ⚙️  Syncing  0.0 bps, target=#2413750 (13 peers), best: #2385193 (0xae38…ad22), finalized #2384896 (0x6bc0…f94f), ⬇ 0.4kiB/s ⬆ 0.2kiB/s

Désolé pour le désagrément.