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

Je continue sur l’histoire des commentaires de transaction en me concentrant sur l’aspect serveur. C’est n’est pas encore clair pour moi si ça touche plus aux Datapods ou aux Indexers, donc je reste sur R&D pour l’instant. [edit, ça a même des chances de finir en Duniter-v2s]

Autre sujet plus sur le côté client : Protocole pour les commentaires de transaction

L’endroit où le commentaire de transaction est le plus souvent affiché actuellement est l’historique des transactions dans Cesium v1. Dans Cesium v2, cette liste provient de l’indexeur duniter-squid qui contient un champ “commentaire” pour les anciennes transactions. Or duniter-squid est fait pour indexer des informations en provenance de la blockchain et on ne souhaite plus avoir les commentaires de transaction en blockchain, car “ce n’est pas leur place”. Je vois donc plusieurs solutions :

1. Publier uniquement un hash du commentaire en blockchain

On avait déjà parlé de cette option sans la creuser davantage. L’inconvénient est que ça demande des modifications non triviales côté blockchain. Les indexeurs pourraient alors simplement lister les hash et le client pourrait récupérer la donnée correspondant à ce hash par un autre mécanisme.
L’avantage est que c’est directement lié à la blockchain, donc il n’y a pas d’écart possible liés par exemple à un rollback BABE.

2. Publier une donnée pointant vers une transaction dans les datapods

Il est facile de faire un document “commentaire de transaction” dans les datapods, mais le faire pointer vers une transaction et l’indexer de manière fiable n’est pas si facile. Pour référer vers une transaction v2, on pourrait utiliser :

  • le hash de l’extrinsic, par ex 0x4ac20edb0cd892ebe9be8f0f932a3f4cbe25bdeba961c4ea43dff9f9b8182869
  • le trio (numéro de bloc, hash du bloc, numéro de l’événement), par ex 1332451 -- 0x3871a72a8cdba3e62b2b632334ccee7bc8c443a48d46b0fe7f8449dafd724bf7 -- 1

L’avantage du hash c’est que c’est indépendant des rollback et donc est valide si la tx passe, il n’y a pas besoin d’attendre qu’elle soit présente dans un bloc pour la soumettre au datapod. Par contre le datapod devra passer par un indexeur s’il veut s’assurer que la transaction a bien été intégrée en blockchain.

L’avantage du trio (en fait juste duo, le numéro de bloc ne sert à rien), c’est qu’il est très facile de demander à la blockchain l’extrinsic référencé, et de récupérer l’émetteur et le récepteur. Il pourra donc indexer ces informations.

Mais se contenter de ça a quand même un inconvénient. Quand on récupère une liste de transactions via un indexeur, il faut faire une deuxième requête auprès d’un datapod avec par exemple une liste de hash ou de trio dont on veut les commentaires associés.

3. Ajouter une source de donnée pour les indexeurs

La solution la plus facile côté client (et la plus complexe côté serveur, c’est souvent comme ça) serait d’ajouter une source de donnée aux indexeurs. Au lieu d’avoir uniquement la blockchain, il écouterait par exemple un canal pubsub sur lequel on diffuserait les nouveaux commentaires de transaction et se synchroniseraient sur un historique conservé par les datapods. Cela permettrait au client de récupérer les transactions et leur commentaire en une seule requête. La soumission se ferait auprès des datapods comme détaillé précédemment.

4. Utiliser la fusion d’API graphql Hasura

On garderait un schéma dans le type “2”, mais l’indexeur offrirait une API simple qui irait chercher les données dans un datapod sans avoir nécessairement les données localement.


La solution qui me plaît le plus est la “3”, mais elle demande pas mal de travail alors j’en discute avant ici.

2 Likes

Je suis un peu sorti des options ci-dessus. Ce qui suit est une sorte de mélange entre les options 2 et 3.

Voici le schéma qui permet à l’appli client de récupérer les commentaires au même endroit que la liste de transactions, c’est-à dire sur l’indexeur squid.

  1. l’app émet une transaction sur le réseau Duniter et attend un retour pour connaître le numéro et hash du bloc dans lequel la transaction a été intégrée
  2. squid qui écoute duniter indexe la transaction sans commentaire
  3. l’app émet un commentaire de transaction auprès des datapods en donnant le hash de l’extrinsic ainsi que le bloc dans lequel la transaction devrait être
  4. le datapod vérifie que la transaction à laquelle le commentaire fait référence existe bien
  5. si c’est le cas, il publie le commentaire de transaction sur un canal pubsub et l’indexe localement
  6. squid écoute le canal pubsub et insère le commentaire de transaction si la signature convient et que la tx est présente dans sa db

Au démarrage d’un nœud squid, il lance l’indexation depuis son nœud archive local et la récupération des commentaires de transaction via l’API graphql d’un datapod de son choix.

Une autre solution comme je l’imaginais au début serait un datapod qui se contente d’indexer sans vérifier puisque de toute façon squid vérifie les transactions avant insertion. Je ne sais pas si c’est plus simple ou stupide :thinking:

image

L’idée de squid est de rester centralisé mais en piochant dans des sources de données qui conservent un historique, comme ça il peut indexer des événements qui ont eu lieu avant qu’il soit lancé.

L’idée du datapod est de constituer une base de donnée décentralisée résiliente aux coupures des différents datapods. Donc le datapod alimente squid, mais squid ne doit pas intégrer la logique lourde et immature que je propose pour les datapods.

Squid doit demander une configuration minimale alors qu’un datapod réclame une attention régulière comme le choix d’une liste de pairs de confiance. Évidemment rien n’empêche quelqu’un d’avoir son datapod et son squid dans des docker sur la même machine, mais ça ne doit pas être un prérequis à l’installation de l’un ou de l’autre. Ça a totalement du sens de faire tourner un squid sans datapod ou un datapod sans squid.

1 Like

La question ici est de savoir si un client peut écrire dans l’indexer.

Je pense que cela n’est souhaitable que dans le cas d’usage où l’indexer devient une passerelle en lecture/écriture vers un node Duniter. Dans l’optique où l’on permet à un client de se contenter de l’indexer.

Sinon la séparation des responsabilités enclin plutôt à ne stocker le commentaire que dans le data-pod, pour qu’ensuite, si besoin, l’indexer le récupère via une indexation automatique. Amha.

J’ai voulu vous en reparler juste après les RML17, mais comme je n’avais pas trop suivi les réflexions je ne savais pas si vous en aviez déjà parlé, je n’ai pas osé, puis c’est sorti de ma tête.

Pour les modifications non-triviales, auxquelles penses-tu ? Publier un hash en paramètre supplémentaire de l’extrinsic (et son exécution publie un évènement) permet de couvrir le besoin, le surcoût n’est pas très important pour la blockchain.

Derrière ça simplifie tout le processus : les datapods n’ont pas besoin de jouer le rôle d’antispam, d’ajouter des droits, etc.

2 Likes

Pour l’instant on utilise la pallet balances directement, là il faudrait la forker pour ajouter notre commentaire. Pourquoi pas, à voir.

Il reste la question du stockage, il faut quand même que l’utilisateur puisse déposer son commentaire quelque part et que ça soit décentralisé.

Finalement je vois donc pas tellement à quel moment ça simplifie le processus, que les datapods vérifient un hash en blockchain ou la présence du hash d’un extrinsic ça revient au même.

En bonus, le hash de l’extrinsic est plus générique, on pourrait commenter n’importe quel extrinsic, pas seulement les transactions. Ça me plaît bien comme idée.

La différence ? La non-répudiation.

Là encore il me faut un peu plus de détails. Si toutes les personnes qui stockaient la donnée décident de l’effacer (par exemple à la demande son auteur) et que personne ne conserve d’archive, quelle est la différence entre avoir un hash en blockchain et un hash sur un index ipfs ?

PS : pourquoi ce mot ? Répudiation — Wikipédia

C’est plutôt : Non-répudiation — Wikipédia. Techniquement celle-ci est assurée peu importe le sens (document publié via blockchain ou via datapod, du moment que celui-ci est signé par la même clé).

Sauf que les datapods ne font pas vraiment partie du protocole blockchain, c’est un système tiers comme un autre. Donc celui qui utilise les commentaires pour y insérer des informations contractuelles n’aura pas le même niveau de garanties selon où se trouve ce hash. La non-répudiation me semble plus forte en blockchain, car tout le monde peut vérifier.

2 Likes

J’ai quatre choses à rajouter :

1. Recoder la pallet balances

On pourrait simplement créer un nouvel extrinsic qui fait un call sur la pallet balances et rajoute simplement l’évènement contenant le hash du commentaire de transaction. Ainsi on wrappe (réutilise) plutôt que de forker.

2. Simplifications

En ayant le commentaire (son hash) géré par Duniter, les datapods n’ont pas à gérer d’antispam sur la création desdits commentaires, puisque ceux-ci émanent de la blockchain et sont donc légitimes par définition.

3. Exhaustivité

En ayant le commentaire (son hash) en blockchain, on sait dire de façon exacte si l’on a bien récupéré l’ensemble des commentaires émis par une clé. Ce qui n’est pas assuré par un système tiers, fût-il P2P, au sens où le référentiel commun ultime est bien la blockchain elle-même.

4. Commentaire générique

Il est aussi possible de créer un extrinsic dédié aux commentaires et qui ne soit pas spécifique aux transferts de monnaie pour arriver au même résultat tout en bénéficiant de la synchronisation inhérente au protocole blockchain.

Extrinsic qui ne ferait que créer un évènement, là encore. Pas besoin de stocker ces commentaires (leur hash).

3 Likes

Revient à

Au sujet du stockage, Hugo parle du stockage du contenu du commentaire, auquel le hash stocké en blockchain fait référence.
(J’ai peu etre mal compris ce que tu signifais)


Un autre avantage que je vois de passer par un événement blockchain, c’est que si les datapods permettent de déréférencer les commentaires par l’utilisateur (émetteur ou récepteur), ou la modération pour le droit à l’oublie, alors le CID en blockchain reste immuable.
Cela répond a la préoccupation de Lumière au sujet des commerçants qui se servent des commentaires comme référence produit (comme cgeek l’avait conçu de base).
Une même référence produit aura le même CID par définition, le commercant n’aura qu’a tenir un registre des ref produit ↔ CID comme preuve absolut des références de transaction.

A contrario, on pourra à jamais prouver qu’une tx était associé à tel commentaire si le commentaire a été enregistré quelque part, meme si déréférencé de tous les datapods. L’oublie est donc partiel.

1 Like

J’émettrais l’hypothèse qu’on ne liste pas souvent les transactions, exceptés quelques comptes particuliers (les siens et quelques autres, toujours les mêmes), et qu’on a encore moins souvent besoin de lire les commentaires. Pour nos propres comptes, la plupart du temps on peut lire le commentaire à la réception de la tx et l’oublier. Si on veut l’historique, un cache client réduit les requêtes.

Dans l’hypothèse où les clients proposent le chiffrement par défaut (ce qui me semble préférable), rares sont les cas où on veut vraiment un commentaire public, donc rares sont les cas où on peut lister des commentaires en défaut de cache.

Cela nuance les gains de performance apportés par l’indexation des commentaires en blockchain.

Si on veut éviter au client de demander aux datapods si une transaction possède un commentaire (pour éviter des requêtes inutiles), mais qu’on ne veut pas du hash du commentaire en blockchain, on peut ne stocker qu’un booléen has_comment.

En ce qui concerne le droit à l’oubli ma vision est que soit on porte son historique (= responsabilité / traçabilité, ce qui a une forte utilité dans les échanges comme base de confiance) soit on décide de renaitre entièrement (c’est le concept d’amour qu’a apporté jean le baptiste à l’humanité: l’ancien toi part avec le fleuve, le nouveau toi naît nu (= chacun a le droit au pardon de l’ensemble de ses fautes passées s’il est prêt à laisser derrière lui les avantages liés à ses fautes). Avoir le beurre et l’argent du beurre en terme de droit à l’oubli ce serait de l’impunité organisée (de donner le droit de continuer à vivre une vie passée tout en donnant le pouvoir d’effacer les preuves de ses fautes/vices = de donner le droit de jouir de ses fautes sans faire face à leur conséquences).

Je crois qu’il est bon de faire appel au pardon dans la communauté (que chacun porte l’historique de ses fautes et qu’on soit indulgents les uns envers les autres tant que chacun œuvre continuellement à graduellement dépasser ses fautes, en comprenant que la faute est humaine et que nous en commettons tous tous les jours, l’essentiel étant d’éviter de les répéter et de porter la responsabilité d’en corriger autant que possible les conséquences). Avec donc deux possibilités: La possibilité principale étant de garder un compte avec une historique indélébile, en portant donc l’avantage et l’inconvénient de ses fautes tout à fait naturelles et en s’améliorant en continu (l’ourobouros). Ou bien pour les personnes qui ont été loin dans la faute ou ont longtemps fauté moins intentionnellement que les autres et qui, se rendant à l’évidence du non-sens d’une telle vie, décident de vivre à l’antipode de ce qu’ils ont connu (d’avoir une nouvelle chance / le droit à tout moment à une nouvelle vie) le fait de laisser tous les avantages de leur ancienne vie derrière eux et de renaitre sous un nouveau compte (le phoenix).

Cultiver le pardon (la tolérance de la faute) c’est embrasser le risque de la faute et embrasser la faute, c’est embrasser sa croissance personnelle (avancer vers une meilleure version de soi). Car en fuyant la faute on fuit le fait de faire / d’essayer / d’explorer (la seule personne qui ne fait pas de faute est celle qui ne fait rien, n’essaie rien, n’explore rien) et en fuyant le fait de faire / essayer / explorer on fuit toute opportunité de croissance.

Dans la silicone valley, comprenant bien que la faute est une des étapes du cycle de croissance il existe l’adage “fail often, fail fast” (fait des fautes que tu n’as pas encore faite le plus souvent possible, mais sors toi rapidement de chaque faute aussitôt que tu en prend conscience). La combinaison de l’anonymat / pseudonymat et de l’indélébilité de ses fautes sous un même compte va, de manière complémentaire, dans ce sens: Pour pouvoir faire fréquemment de nouvelles fautes (des fautes d’un nouveau type) il faut se trouver dans un environnement qui est tolérant et pour ne pas rester dans la faute longtemps (“fail fast”) il faut bien que ces fautes soient indélébiles (le regard de la communauté “la Lumière” étant à la fois ce qui nous fait rapidement prendre conscience de nos fautes et ce qui nous pousse à nous repentir raisonnablement rapidement de celles-ci / à nous élever en la plus puissante version de nous même). L’ancien monde est un monde qui cultive l’affaiblissement de l’individu (qui organise le fait qu’il fuit sa propre croissance), le nouveau que nous construisons peut-être un monde de puissance individuelle (qui organise le fait pour chacun de cultiver le fait de s’améliorer en permanence / de cultiver sa croissance / pour chacun d’embrasser toujours plus de puissance dans son être intérieur).

Une chose aussi, peut-être, à garder à l’esprit est qu’il est bon d’éviter de faire des décisions à la place des gens, car ce faire serait leur voler leur libre arbitre et voler le libre arbitre d’une personne c’est lui voler la vie, au sens spirituel (c’est une fraction de meurtre spirituel).

Tant que les choses restent dans leur état actuel en ce qui concerne les commentaires (et c’est très bien ainsi), personne n’est obligé d’écrire un commentaire quand il envoie une transaction (tout comme personne n’est obligé de faire telle ou telle action en général dans la vie) mais s’il le fait, alors il doit porter ce commentaire / cette action dans cette “vie” = sous ce compte (on a pas le droit de choisir à la place des gens leur actions, par contre on a pas le droit non plus, je crois, d’œuvrer à rendre leur fautes invisibles = complicité de destruction de preuves de leur fautes).

Qu’en est il des fautes que l’on peut faire dans les commentaires de transaction que l’on émet?

La faute est humaine. Un des grands vices de notre société est de pousser les gens à prétendre ne pas faire de fautes, à prétendre à la perfection (= à mentir, car tout le monde fait des fautes en permanence, le plus souvent inintentionnellement et la perfection n’existe pas). Je crois que pour construire un monde sain il faut éviter de reproduire cette erreur (cette environnement qui prétend à la perfection, qui prétend à l’absence de faute, étant devenu une sorte de norme pour nous) et c’est en évitant de la reproduire qu’on nourrira la résurgence de la tolérance à l’intérieur de ce monde, qui est tout à fait notre nature, qui est le “par-défaut” de l’humain, mais qui a été détruite à travers le mensonge de la perfection (la facilitation omniprésente de ce mensonge) et l’impunité organisée (la facilitation omniprésente de l’effacement de la preuve de ses fautes passées tout en continuant à jouir de ces fautes).

Quand on prétend à la perfection on souffre (car on poursuit un mensonge et le fait de poursuivre ce qui n’existe pas ne peut amener qu’à la souffrance).

Qu’en est-il des commentaires d’autres personnes sur des transactions entrantes sur notre compte?

Le fait qu’ils soient indélébiles (sauf possibilité éventuelle que les deux partis s’accordent à l’effacer, ce qui ne me semble pas tant condamnable à implémenter) est clef dans le géni que dans l’état des choses ces commentaires sont un outil tout à fait utilisable pour dénoncer la faute là où elle grandit.

Et là où l’on peut tout à fait porter de fausses accusations à travers les commentaires de transactions que l’on envoie sur le compte d’autrui, nous ne sommes pas responsables des actions des autres, mais que seulement des nôtres, et là où le mensonge prend l’ascenseur et la vérité prend l’escalier, cette dernière arrive toujours à destination et fait lumière. La transparence des comptes est du génie, car elle invite chacun à pouvoir faire un minimum de recherche (“due diligence” en anglais) pour trier le bon grain de l’ivraie. Ça cultive le réflex d’aller collecter des informations soi-même au lieu d’internaliser un jugement émis par un tiers. Et là où le receveur d’une fausse accusation la porte un temps, l’émétteur de telles accusations, dans un monde qui ne facilite pas la destruction de preuves, les porte toute cette “vie” (ce compte y est lié de manière indélébile). La justice étant nature, le préjudice dont souffre le récepteur de fausses accusation dure un temps, mais celles-ci avec le temps se transformeront en médailles indélébiles sur son compte qui feront que ce préjudice sera couvert en son temps d’une bonne mesure d’abondance compensatrice.

A été créé un monde de mensonge, d’impunité organisée, de souffrance, d’intolérance (car organiser l’apparence de la perfection, en donnant le pouvoir d’effacer la trace de ses fautes tout en restant dans la même vie de faute, est la source même de l’érosion de la tolérance qui pourtant est la nature, le “par-défaut” de l’humain et de l’avènement de l’intolérance, que nous connaissons bien chez les autres, mais qui est encore grand en nous). C’est à nous de créer, si nous le décidons, à travers les occasions granulaires et toujours répétées que nous avons de faire les choix dans ce que l’on construit qui définiront l’avenir, en lieu et place de cet ancien monde un nouveau monde de vérité, de responsabilité, de pardon et de tolérance.

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).

A quels gains de performance fais-tu référence ? Je ne crois pas avoir lu ça dans ce topic :thinking:

Au fait qu’en recevant l’enregistrement d’une transaction, si le hash du commentaire n’est pas indiqué en blockchain, le client doit demander au datapod si un commentaire existe pour cette transaction. Mais si l’agrégation du commentaire à la transaction est faite côté serveur (datapod/indexeur/autre), alors ça ne pose pas de problème, je n’y avais pas pensé. (le client demande des transactions et obtient gratuitement les éventuels commentaires)

À propos de la différence en terme d’information entre stocker le hash en blockchain ou non : si le hash n’y est pas, le destinataire peut prétendre ne pas avoir reçu le commentaire, et donc que la transaction ne respecte pas tel contrat. Mais même s’il y est, on peut prétendre ne pas avoir trouvé le commentaire correspondant au hash, et on ne peut pas prouver la mauvaise foi de cette affirmation.

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.

@Lumiere je te demande humblement de ne pas flooder ce sujet avec des pavés. Synthetise ta pensée en quelque lignes où crée un sujet moins technique sur ton opinion fleuve. Mais on est sur un forum technique pour avancer sur des solutions techniques. Les avantages et inconvénients des solutions proposées sont exprimés de façon courte et synthétiques. Merci de ta compréhension.

En effet c’est très important pour Tikka. Car c’est très pratique de pouvoir automatiser le rapprochement entre les factures et les transactions. Mais ce n’est pas obligatoire car ce cas d’usage n’a pas besoin de prouver quoi que ce soit. Le rapprochement se fait à la main si cette fonctionnalité n’est pas possible. Je pourrais même ajouter dans Tikka la possibilité de mettre manuellement une référence de facture ou un commentaire sur une transaction, stocké localement pour la compta interne du commerçant.

Je ne comprends pas bien cette phrase :thinking: en tout cas 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.

Tu devrais pouvoi vérifier via Polkadot.js en pointant sur ton nœud miroir (je suppose que son nom n’étant pas archive il ne fait que miroir) en consultant un bloc initial genre #0 ou #1, et en vérifiant que tu peux le consulter (pas juste la tête mais bien le corps avec) mais pas obtenir un état de la blockchain sur ces blocs.

1 Like

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