Configuration réseau pour un bon fonctionnement pair à pair

Networks ĞDev
,
41
  • Mon noeud Smith ne va pas bouger
    • mais pas un noeud archive, du coup est-il utile de l’ajouter?
  • Mon noeud Archive pourrait devoir bouger d’ici 1 an ou 2 si on arrive pas à réduire l’usage disque
    • (j’ai un peu plus de 100GB disponible pour Archive + Squid)
    • Est-ce que c’est considéré comme stable du coup ? :slight_smile:
42

Pas pour les bootnodes : les bootnodes sont inscrits en dur dans le binaire de Duniter, donc ils sont difficiles à mettre à jour. Il vaut mieux n’y inscrire que des nœuds dont la configuration est supposée stable sur le long terme.

Aussi, je me suis renseigné auprès de quelques collègues pour y voir plus clair sur cette histoire de bootnodes, et on me dit qu’il est préférable que les nœuds qui produisent des blocs (les forgerons, pour nous) ne soient pas dans les bootnodes. En effet, les bootnodes ont plus de charge réseau à gérer et ils sont en première ligne en cas d’attaque DoS sur le réseau P2P.

Il est préférable que les nœuds forgerons n’exposent pas leur endpoint P2P publiquement ; sinon, un attaquant peut les DoS pour les empêcher de produire leurs blocs.

Les nœuds bootnodes n’ont pas besoin d’être des archives : ils servent seulement à la découverte du réseau. Un nouveau nœud qui essaye de se synchroniser va d’abord découvrir le réseau en partant des bootnodes, puis commencer sa synchronisation. Tant qu’il découvre au moins un nœud archive, il pourra se synchroniser. En cas d’échec de la synchronisation, il est possible de saisir manuellement l’endpoint P2P d’un nœud archive avec l’option CLI :
--reserved-nodes /ip4/1.2.3.4/tcp/30333/p2p/12D3KooW...

43

Du coup, si je prend mon exemple; ajouter un noeud “miroir” sur le même serveur qui contient mon noeud forgeron ne serait pas bon non plus, vu que c’est la même machine et la même destination réseau (même ip publique).

Le mieux est sans doute de mettre un noeud “miroir” sur un autre VPS que je possède qui n’a pas de noeud “forgeron” actif dessus ?

44

Oui, les bootnodes doivent être des nœuds miroir sur une machine qui ne fait rien de critique à côté. Ça peut être une machine avec peu de stockage, car il est acceptable d’avoir une configuration de pruning agressive pour un bootnode.

45

Certes, mais Mon noeud forgeron a été offline (Hugo) → faute d'espace disque et Soucis potentiel d'espace disque nécessaire pour la V2 - #24 by HugoTrentesaux → (Disk space usage is difficult to predict. · Issue #7962 · paritytech/polkadot-sdk · GitHub). Il faudrait implémenter l’élagage des headers et les zk warp proof.

46

Je viens d’ajouter un nœud miroir sur mon 2ème VPS, avec

    environment:
      #...
      - DUNITER_PRUNING_PROFILE=light

Testé avec:

J’ai fais une MR pour l’ajouter à la liste des p2p :slight_smile: :

47

J’avais cru comprendre qu’un noeud contenant les headers suffisait comme source de synchronisation, cela m’étonne que le réseau nécessite au moins un noeud archive, à part pour les indexers.

48

Oui, ces propos sont contradictoires. Je suppose que dans la seconde citation le mot archive est en trop et peut être enlevé ? Il s’agit d’une erreur ? J’étais aussi buggé hier soir en lisant le message d’Éloïs.

49

Moi je le comprend comme, l’ “utilisateur” qui va utiliser le BootNode mirroir pourra récupérer les autres noeuds qu’il référence, qui devraient contenir au moins un noeud Archive.

50

Oui, tu as raison. Ça fait sens. Du coup, le premier nœud lancé par poka avait les trois fonctions bootnode, forgeron et archive ?

51

Du coup, ce serais sans doute intéressant d’ajouter un référencement manuel vers des noeuds Archive dans la configuration de ce genre de BootNodes ?

Quelqu’un à déjà utilisé la variable d’environnement DUNITER_PUBLIC_ENDPOINTS ?

Documentée ici

Path to a JSON file containing public endpoints to gossip on the network. The file should use the following format:
{"endpoints": [ { "protocol": "rpc", "address": "wss://gdev.example.com" }, { "protocol": "squid", "address": "gdev.example.com/v1/graphql" }]}

Edit:
Est-ce que cette variable DUNITER_PUBLIC_ENDPOINTS peut également définir les endpoints “p2p” (ce n’est pas dans l’exemple) ?

52

Ça dépend du type de synchro utilisée, mais par défaut la synchro nécessite de recevoir tous les blocs, donc il faut bien un nœud archive pour ça.

Les 3 types de sync, en ultra-résumé :

  • full (par défaut) : télécharge et exécute tous les blocs depuis le genesis.
  • fast (option --sync fast) : télécharge tous les blocs mais ne vérifie que les headers.
  • warp (option --sync warp) : ne télécharge que les justifications GRANDPA, c’est-à-dire les déclarations de changement de set de validateurs signées par au moins deux tiers des validateurs du set précédent, puis télécharge tous les blocs après la justification GRANDPA la plus récente.
53

Petite question, pour la MR de changement de g1.json est-ce que je la merge moi-même ou c’est mieux que quelqu’un relise ?

54

Non, ce n’est pas ce qu’on appelle un nœud archive.

J’ai fait une explication détaillée sur le sujet : Élagage de l'état, élagage des blocs, noeuds archive et miroir.

TLDR:

55

Merci pour les infos sur les types de synchronisation, cela m’éclaire mieux sur ce que tu veux dire par archive !

Tu entends nœud archive comme contenant tous les blocs, avec raison, moi tous les états. Mais on est d’accord sur le fait qu’il doit y avoir un nœud contenant tous les blocs pour se synchroniser, pas forcément tous les états.

Comme disait mon grand père : “Cela va sans dire, mais ça va mieux en le disant.” :wink: