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](https://duniter.org/wiki/duniter-v2/configure-docker/#environment-variables), cf [docker entrypoint (L67-L80)](https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/2b050e27c5b435833f4c1d46262c665adc4b0c93/docker/docker-entrypoint#L67-L80). Pour un nœud validateur, on recommande d’utiliser le profile “light” : [Duniter | Run a smith node](https://duniter.org/wiki/duniter-v2/run-smith/) 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
> [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/12):
>
> > [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/11):
> >
> > créer un évènement
>
> Revient à
>
> > [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/12):
> >
> > > [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/11):
> > >
> > > stocker ces commentaires (leur hash)
>
> Non je pense qu’il existe une différence : à mon avis les évènements d’un block sont élagués avec leur bloc pour un nœud non-archive. Cela reste à confirmer mais, vu la philosophie de Substrate, je serais surpris du contraire.
>
> Là où stocker les hash génère de façon 100% certaine un donnée permanente dans le Storage (pire : historisée pour un nœud archive).
➡ 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](https://github.com/paritytech/trie) des états, donc dans le cas des commentaires de transaction, un simple pointeur vers les événements contenus dans les blocs.
> [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/17):
>
> Pour moi les évènements sont stockés sur tous les noeuds, car ce n’est pas un état du storage et donc le droit à l’oubli est impossible.
>
> Je m’etait posé la question car je trouvais dangereux pour la blockchain de potentiellement perdre des informations à jamais si plus personne ne faisait tourner de noeud archive.
>
> Quand j’ai compris que la seule difference entre un noeud archive et un noeud simple est l’historique des états du storage à chaque bloc, et que l’on peut donc reconstruire un noeud archive à partir d’un noeud simple, j’etais rassuré.
>
> Mais je vais chercher la preuve de cela dans la doc Substrate parce que c’est important.
➡ 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_.
> [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/19):
>
> les évènements n’étant pas nécessaires à la State Transition Function (STF), je ne vois aucune raison de les conserver lors de l’élagage d’un bloc
➡ 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.
> [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/20):
>
> Je pense qu’une mauvaise compréhension du comportement du Storage rôde dans l’air (je m’inclus dedans) et cause ces incompréhensions.
➡ d’où ce sujet 😸
> [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/23):
>
> **les événements sont purgés** au delà du nombre de bloc configuré par l’option purge (256 par défaut je crois)
On ne “prune” les blocs (pas “purge”) que pour le profile “light”.
> [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/28):
>
> Je trouve la doc Substrate très pauvre sur ces sujets, j’ai beaucoup de mal à trouver des informations détaillés sur ces sujets.
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#/](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](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/21)
> **citation**
>
> > [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/21):
> >
> > C’est à peu près ce que j’essaye d’exprimer oui, je vais le reformuler :
> >
> > Je pars du principe (possiblement erroné, ça reste à confirmer) que, bien que toute écriture de donnée impacte le Storage (la BDD, en gros) et notamment le Merkle Root du bloc courant, toute écriture ne va pas forcément impacter le Merkle Root _des blocs suivants_.
> >
> > Autrement dit : que quand un bloc est traité et accepté, il va construire son propre arbre de Merkle dont certaines branches vont “reprendre” tout ou partie des données de l’état au bloc précédent, mais que certaines autres branches seront purement et simplement écrasées.
> >
> > Je prétends que les évènements font partie de ces données systématiquement écrasées en intégralité par chaque bloc, et que donc par définition ce type de donnée n’impacte pas les blocs suivants et que forcément, à l’élagage du bloc, la donnée disparaît et ne vient jamais “gonfler” la BDD contrairement à des données “métier” (les comptes, les transactions, etc.).
> >
> > Voilà pourquoi les évènements me semblent une très bonne façon d’indexer les hash de commentaires.
> >
> > Et c’est également pour cela que je dis que stocker ces hash comme une donnée “métier” viendrait au contraire créer une donnée stockée par tout nœud (archive ou pas) et créerait même une donnée à stocker de façon historisée pour un nœud archive (en gros = stocker tous les évènements de tous les blocs).
> >
> > edit : tiens bah je suis allé vérifier sur la documentation Substrate, c’est bien comme ça que ça se passe :
> >
> > > This function places the event in the System pallet’s runtime storage for that block. At the beginning of a new block, the System pallet automatically removes all events that were stored from the previous block.
> >
> > [Source](https://docs.substrate.io/build/events-and-errors/)
Et au sujet de la reconstruction de l’état.
> **citation**
>
> > [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/24):
> >
> > Oui, je suppose que le nœud full conserve les blocs _avec body_ (donc avec les extrinsics dedans) tandis qu’un _light node_ par exemple ne synchronise que le header de chaque bloc. Ce qui fait que ce dernier type de nœud est le seul à ne pas pouvoir reconstruire l’intégralité des données de la blockchain, tous les autres le peuvent.
Autre reformulation par tuxmain.
> **citation**
>
> > [@Options pour gérer les commentaires de transaction côté serveur](https://forum.duniter.org/t/options-pour-gerer-les-commentaires-de-transaction-cote-serveur/12241/26):
> >
> > Je ne comprends pas quel est le débat. Pour récapituler :
> >
> > - La blockchain est une suite de blocs.
> > - Les blocs contiennent des extrinsics.
> > - Les nœuds d’archive ont tous les blocs.
> > - Les nœuds normaux ont seulement les derniers blocs.
> > - Le runtime exécute du code pour chaque extrinsic, qui peut générer des événements et modifier l’état, **de manière déterministe** (fonction du bloc et de l’état).
> > - Les événements ne sont pas stockés.
> >
> > Donc :
> >
> > - Les extrinsics sont publics.
> > - Les événements peuvent être retrouvés facilement à partir d’une archive (on prend un ancien état soit à partir d’une archive des états, soit en enchaînant les anciens blocs, et on exécute le bloc suivant).
> >
> > Les événements ne sont là que pour aider les indexeurs et clients.
* * *
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.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [13 May 2024 15:18 UTC](https://forum.duniter.org/t/elagage-de-letat-elagage-des-blocs-noeuds-archive-et-miroir/12255/2 "2024-05-13T15:18:21Z")
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**](https://docs.substrate.io/reference/glossary/#header) 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
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [13 May 2024 16:55 UTC](https://forum.duniter.org/t/elagage-de-letat-elagage-des-blocs-noeuds-archive-et-miroir/12255/3 "2024-05-13T16:55:02Z")
> [@poka](#):
>
> La doc de substrate est trop ambiguë à ce sujet:
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 …
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [14 May 2024 08:21 UTC](https://forum.duniter.org/t/elagage-de-letat-elagage-des-blocs-noeuds-archive-et-miroir/12255/4 "2024-05-14T08:21:04Z")
Ç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](https://substrate.stackexchange.com/questions/6032/how-can-a-full-node-reconstruct-the-entire-chain-state-using-just-block-headers)
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](https://github.com/substrate-developer-hub/substrate-docs/pull/2153)
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [14 May 2024 14:20 UTC](https://forum.duniter.org/t/elagage-de-letat-elagage-des-blocs-noeuds-archive-et-miroir/12255/5 "2024-05-14T14:20:46Z")
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 !
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [14 May 2024 15:49 UTC](https://forum.duniter.org/t/elagage-de-letat-elagage-des-blocs-noeuds-archive-et-miroir/12255/6 "2024-05-14T15:49:15Z")
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](https://github.com/substrate-developer-hub/substrate-docs/actions/runs/9076077245/job/24938024951?pr=2153)
…