Élagage de l'état, élagage des blocs, noeuds archive et miroir

Vu certains posts sur le fil Options pour gérer les commentaires de transaction côté serveur, il me semble utile de faire un rappel sur l’élagage de l’état ou des blocs, et les différentes configurations possibles pour un nœud Duniter.

Options disponibles

Il y a deux types d’élagages possibles : le state pruning et le block pruning.

> duniter --help
      --state-pruning <PRUNING_MODE>
          Specify the state pruning mode.
          
          This mode specifies when the block's state (ie, storage) should be pruned (ie, removed) from the
          database. This setting can only be set on the first creation of the database. Every subsequent run
          will load the pruning mode from the database and will error if the stored mode doesn't match this
          CLI value. It is fine to drop this CLI flag for subsequent runs. Possible values: - archive: Keep
          the state of all blocks. - 'archive-canonical' Keep only the state of finalized blocks. - number
          Keep the state of the last number of finalized blocks. [default: 256]

      --blocks-pruning <PRUNING_MODE>
          Specify the blocks pruning mode.
          
          This mode specifies when the block's body (including justifications) should be pruned (ie, removed)
          from the database. Possible values: - 'archive' Keep all blocks. - 'archive-canonical' Keep only
          finalized blocks. - number Keep the last `number` of finalized blocks.
          
          [default: archive-canonical]

L’élagage des états permet de ne conserver que les états récents, mais les états anciens peuvent toujours être reconstruits à partir de l’historique des blocs.

L’élagage des blocs permet de ne conserver que la tête utile pour ajouter de nouveaux blocs, mais ne permet plus la reconstruction de l’historique.

Noms simplifiés

Pour simplifier l’utilisation, nous avons introduit la variable d’environnement DUNITER_PRUNING_PROFILE pour la configuration via docker, cf docker entrypoint (L67-L80). Pour un nœud validateur, on recommande d’utiliser le profile “light” : Duniter | Run a smith node car le reste serait superflu. Bien entendu, cela implique de conserver par ailleurs des nœuds miroir a minima pour éviter de perdre l’historique. Pour faire tourner duniter-squid, il faut lui fournir un endpoint d’un nœud archive, de préférence local parce qu’il y aura beaucoup de requêtes.

Pour simplifier la compréhension, je propose de nommer les nœuds en sous-entendant le profile associé :

  • forgeron → light (élagage d’état et des blocs)
  • miroir → default (uniquement élagage d’état)
  • archive → archive (pas d’élagage)

Remarques

:arrow_right: Un nœud “miroir” n’élague que les états, donc il stocke quand même les blocs, ce qui est nécessaire pour pouvoir reconstruire l’historique des états.
Un nœud “archive” conserve en plus un historique de la Patricia Merkle Tree des états, donc dans le cas des commentaires de transaction, un simple pointeur vers les événements contenus dans les blocs.

:arrow_right: Les événements font partie des blocs (de leur merkle tree), donc sont stockés sur les nœuds qui ne les élaguent pas.
On peut reconstruire un nœud archive à partir d’un nœud miroir, mais pas à partir d’un nœud light.

:arrow_right: Effectivement. Les événements sont dans le storage uniquement parce que les blocs sont dans le storage (via leur state root). Donc quand on élague un bloc (nœud light), l’événement disparaît. Par contre, il est conservé sur les nœuds miroir.

:arrow_right: d’où ce sujet :smile_cat:

On ne “prune” les blocs (pas “purge”) que pour le profile “light”.

Cgeek avait partagé une présentation vidéo que je ne retrouve plus, mais les slides sont ici :

https://polkadot-blockchain-academy.github.io/pba-book/substrate/storage/slides.html#/

Reformulations

Vous trouverez tout ça formulé autrement dans le post Options pour gérer les commentaires de transaction côté serveur - #21 by cgeek

citation

Et au sujet de la reconstruction de l’état.

citation

Autre reformulation par tuxmain.

citation

Voilà, j’espère que ça permettra de reprendre la discussion sur : veut-on que les hash des commentaires de tx fassent partie du consensus “dur” en blockchain, ou préfère-t-on que cela fasse partie d’un consensus “mou” hors blockchain.

5 Likes

Donc il est faux de dire que les noeud mirroir (full node) ne gardent que les 256 derniers blocs par défaut.
Ils gardent tous les blocs entier depuis le genesis, mais élaguent leurs états.
Je pense que mon incompréhension venait de là.

La doc de substrate est trop ambiguë à ce sujet:

Although older blocks are discarded, full nodes retain all of the block headers from the genesis block to the most recent block to validate that the state is correct. Because the full node has access to all of the block headers, it can be used to rebuild the state of the entire blockchain by executing all of the blocks from the genesis block

2 Likes

Ce n’est même plus ambigu, c’est carrément faux ! Ou alors il faut préciser que d’une façon ou d’une autre il y a un accès aux blocs entiers …

1 Like

Ça a déjà perdu quelqu’un : blockchain - How can a full node reconstruct the entire chain state using just block headers? - Substrate and Polkadot Stack Exchange

Je tente donc une ré-écriture, mais les connaissant ils vont pas vouloir changer à ce point le texte initial : Rephrase networks-and-nodes.md documentation by Hugo-Trentesaux · Pull Request #2153 · substrate-developer-hub/substrate-docs · GitHub

5 Likes

Ahaha oui en effet je suis pas tout seul ><
Bah au moins ta MR est très claire, j’espère vraiment qu’ils vont au moins y répondre pour savoir le vrai du faux là dedans.
Parceque franchement ça m’étonne fortement qu’une erreur aussi grossière se soit glissé dans leur doc, c’est pas possible.
Mais autrement, la reconstruction des états intermédiaires à partir des full nodes resterait un mystère, de la magie. Donc hâte d’avoir le fin mot de l’histoire !

On pourrait ptetre aussi en profiter pour corriger tous les liens morts en 404 de leur doc pointé par leur linter en CI: Rephrase networks-and-nodes.md documentation · substrate-developer-hub/substrate-docs@bbe2aeb · GitHub

2 Likes