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

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. Ils sont totalement décorrélés du droit à l’oubli.

Mettre les hashes de commentaires en extrinsics cause :

  • gestion peut-être un peu plus facile pour les indexeurs
  • gestion presque inchangée pour les clients, si les indexeurs font le lien tx->commentaire eux-mêmes
  • extrinsics un peu plus lourds (d’un facteur <100%)
  • aucun droit à l’oubli du hash du commentaire
  • garantie cryptographique qu’un commentaire est bien antérieur à l’extrinsic (sans besoin de se fier au filtrage de l’indexeur qui pourrait être corrompu et accepter des commentaires des jours après la transaction)

La garantie d’intégrité du commentaire (càd qu’il a bien été publié à la date de la transaction, et non modifié depuis) semble intéressante pour augmenter la sécurité de protocoles tels que ĞMixer ou la confiance de commerçants. Son (faible) impact sur la vie privée et sur le déni plausible peut être amoindri grâce aux méthodes cryptographiques que j’ai décrites ici.

Aucun de ces arguments pour ou contre n’étant très fort, le dernier point me semble le plus significatif et faire pencher la balance du côté “hash du commentaire en blockchain”.

1 Like