Soucis potentiel d'espace disque nécessaire pour la V2

Support Duniter-v2
21

J’avoue que je ne saisis pas la nuance entre block pruning et state pruning; ni entre block et state quelle partie prend beaucoup d’espace disque.

Quand on spécifie la variable d’environnement:

DUNITER_PRUNING_PROFILE=light
# OU
DUNITER_PRUNING_PROFILE=archive

Est-ce que cela impacte les 2 “types” de pruning ?

Et du coup ma question plus globale est quelle est la configuration minimale pour que l’on puisse utiliser un noeud duniter comme source de synchronisation d’un nouveau noeud - et quel serait l’espace disque utilisé avec cette configuration ?

22

Les blocs décrivent les transitions d’états. C’est léger puisqu’on en broadcast toutes les 6 secondes.

Un état est tout le storage à un numéro de bloc donné. C’est lourd et ça le sera de plus en plus.

2 Likes
23

Sachant que les nœuds archive stockent le storage pour tout les blocs et que les indexers ont principalement besoin de :

  • Historique des Virements (extrinsics ?)
  • Pseudonymes des identités (événements ?)

A-t-on vraiment besoin d’un nœud archive pour l’indexer ?

Ne peut -on avoir les deux infos plus lentement, mais aussi surement avec les nœud miroir (ou bien les événements sont aussi stockés dans le storage ?)

Idée à la con :

  • On a aucun nœud archive sur notre réseau, car c’est le mal !
  • Un indexer qui se lance, regarde le bloc courant de son nœud miroir, et s’y abonne pour capturer les infos au fil des blocs. Puis lance en parallèle un nœud archive temporaire, juste pour y puiser ce qui lui manque entre le bloc genesis et le bloque courant. Puis éteint et supprime le nœud archive ! CQFD !
24

La réponse courte de tuxmain est bien. Si tu veux un peu plus d’explications, tu en trouveras ici : Élagage de l'état, élagage des blocs, noeuds archive et miroir.

L’indexeur a besoin uniquement des événements qui devraient en théorie pouvoir être récupérés sans nœud archive. En pratique squid est basé dessus donc ça demanderait des développements significatifs en plus.

J’ai posé la question sur le github de substrate, et apparemment on pourrait implémenter l’élagage des headers pour gagner de la place :

Reste à faire des calculs (au moins en ordre de grandeur) de qu’est-ce qui prend quoi comme place.

2 Likes