Options pour gérer les commentaires de transaction côté serveur

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.

Jusque-là je suis entièrement d’accord avec cette phrase, ça me semble normal. En fait avant de m’intéresser un peu plus au STF pour ma culture, j’aurais eu tendance à dire que c’est le cas pour toute écriture en blockchain.
Mais si je reformule pour essayer de mieux comprendre, chaque élément inscrit en blockchain correspond au changement d’état d’une clé du storage, donc présent sur tous les nœuds, là où les événements (également présents en blockchain) ne correspondent pas du tout à un changement d’état du storage, mais juste un log de notification immuable. Est-ce correct ?

Par contre ce que je ne comprends pas, c’est la seconde partie de réponse :

Les événements sont tous historisés de manière immuable, de façon 100% permanente dans les nœuds archives, car inscrits dans les blocks, c’est d’ailleurs leur fonction. C’est ainsi que les indexers recréent tout l’historique de changements d’états.

Donc inscrire les hash (CID) en simple événement revient à les stocker de manière permanente et immuable sur tous les nœuds archives.

Donc les remarques concernant l’aspect immuable de ces hash tiennent. Si présents dans les événements, alors n’importe qui ayant en possession une copie texte de chaque commentaire de transaction en clair (avec un datapod qui pin tout sans prendre en compte les demandes de suppression par exemple) pourra prouver à jamais qu’il s’agissait des commentaires originels, même si désindexés de tous les datapods.

1 Like