Les traitements événementiels

Sujet technique, similaire à Production du DU.

Dans ma rédaction du protocole, je passe actuellement sur les traitements événementiels internes, c’est-à-dire des traitements qui doivent intervenir à un instant donné et qui ne sont pas déclenchés par une action utilisateur mais par la blockchain elle-même, dont voici la liste :

  • Expiration de certification (au bout de 2 ans) [sigValidity]
  • Expiration d’adhésion (au bout de 1 an) [msValidity]
  • Révocation implicite (1 an après la parte de statut de membre) [msValidity x 2]

Il y a également l’événement de DU, mais celui-ci ne pose pas problème car sa complexité d’implémentation est en O(1) vu qu’il n’y a au plus qu’un seul DU par bloc. Ce qui n’est pas le cas des certifications, adhésions et révocations qui sont en O(N) si l’on doit toutes les parcourir à chaque fois, N étant le nombre de membres.

Il y avait aussi les événements de péremption des documents en piscine, mais comme celle-ci va être retirée je les mets juste pour mémoire.

Anciens événements de péremption en piscine.
  • Péremption de l’identité (pas devenue membre au bout de 2 mois) [idtyWindow]
  • Péremption de la certification (non consommée au bout de 2 mois) [sigWindow]
  • Péremption de l’adhésion (au bout de 2 mois) [msWindow]

La recherche par intervalle est coûteuse

Le gros problème de ces événements internes, c’est la difficulté de les retrouver en base de données : il faut faire une recherche par intervalle de valeurs, par exemple trouver toutes les certifications qui ont expiré entre le 06/01/2021 12h (bloc(t - 1)) et 12h10 (bloc(t)).

Ce genre de traitements est coûteux car il faut « scanner » les données (d’où le O(N)). De plus l’API du Storage n’offre pas de fonctions de recherches par intervalle de valeur pour des raisons structurelles.

Créer un index applicatif

Le seul moyen dont nous disposons est de créer nous-même un index mais de niveau applicatif. C’est-à-dire des entrées dans la base de données qui référencent d’autres données.

Par exemple avoir une entrée Storage["cert_expiry"]["2022-01-01 02:34:00"] = [id_cert_1, id_cert2] qui liste les certifications 1 et 2 qui sont censées expirer à 02h34 le 01/01/2022.

Ainsi on n’a pas à parcourir la liste entière des certifications, mais simplement une petite sous-partie puis lire les certifications elles-mêmes.

Le choix de l’index

Mettre une date-heure me semble correct, dans la mesure où l’on a un bloc toutes les 6 secondes, ça veut dire qu’entre deux bloc affichant l’intervalle [t-1, t] on doit en moyenne aller faire 6 lectures pour Storage["cert_expiry"] à chaque bloc pour les expirations de certifications, 6 autres pour les adhésions et 6 autres pour les révocations.

A mettre en perspective des 14516 transactions monétaires maximales théoriques par bloc, soit donc le double en nombre de lectures (l’émetteur, le bénéficiaire) donc environ 29000 lectures/bloc : 18 lectures ne sont rien.

On pourrait toutefois choisir de mettre en index un n° de bloc, arguant qu’un bloc se produit théoriquement toutes les 6" alors on peut calculer le n° du bloc auquel l’expiration se produit. C’est aussi très direct. Néanmoins c’est moins exact, le temps inter-bloc n’étant pas garanti avec Substrate.

Je préfère donc l’index avec date-heure d’expiration, plus précisément un timestamp en UTC+0.

C’est ce que je compte indiquer dans le protocole comme changement pour Duniter V2S.

5 « J'aime »

Est-ce que les événements de péremption de ces documents On-chain pour Duniter v2 Substrate doivent être pris en compte ici, où est-ce déjà géré par Substrate ?

Tu veux dire ceux qui étaient en piscine avant ?

Oui.

Lors du renouvellement d’un certificat il va falloir parcourir cette liste pour mettre à jour l’enregistrement associé à l’ancienne date d’expiration.

Dans la mesure où il n’y a plus de piscine et que ces contraintes temporelles étaient là pour contrer le spam sur la piscine, je ne vois pas où mettre ces contraintes :

  • Péremption de l’identité : celle-ci est inscrite on-chain, elle peut prendre le temps qu’elle veut pour devenir membre.

    Par contre on peut lui appliquer la révocation implicite, je rajoute !

  • Péremption de la certification : ça ne peut pas arriver, la certification est inscrite et valable en blockchain directement.
  • Péremption de l’adhésion : idem que certification.

Tout à fait.

1 « J'aime »

Aujourd’hui, on observe régulièrement des aspirants membres qui créent une identité, reçoivent 1 ou 2 certifications puis oublient leurs identifiants. Il me semble bon que ces certifications périment au bout de 2 mois pour revenir dans les certifications disponibles de leurs émetteurs.

… Mais après tout, avoir une certification bloquée « inutilement » pendant deux ans peut aussi amener les certifiants à être plus précautionneux, ce peut être une bonne chose donc :slight_smile:

deux remarques :

  1. oubli de trousseau

Aujourd’hui, La péremption de (identité + adhésion) au bout de 2 mois permet à des novices d’oublier leur trousseau, et pouvoir être tout de même certifié par la suite (après les deux mois) sur une identité liée à une autre clef pub.

Si l’adhésion ne périme qu’au bout d’un an, et l’identité est révoquée automatiquement au bout de deux ans comme tu sembles le proposer, qu’arrive-t-il aux comptes de ces novices ? Peuvent-ils être certifiés, malgré une autre identité potentiellement certifiable ?

Il me semble que prévoir un mécanisme de péremption rapide en cas de non-passage membre autorise ce genre d’erreurs aux novices, et que c’est une bonne chose.

Aujourd’hui, au bout de deux mois, l’identité périme mais n’est pas révoquée, ce qui permet de redemander une identité + adhésion sans changer de trousseau. C’est très facilitant pour les nouveaux utilisateurs.

1 « J'aime »

Le stock est quand même élevé (100 certifications), le droit à l’erreur est déjà en place je trouve.

OK, d’un autre côté certains trouvent que 2 mois c’est un peu stressant aussi pour réussir à entrer.

Peut-être qu’on pourrait alors introduire une nouvelle action permettant de « repousser » la limite des 2 mois pour ceux dont je parle, tout en conservant la péremption (qui concrètement sera une révocation implicite - donc perte définitive du pseudo notamment).

Ce qui répondrait également à :

1 « J'aime »

Substrate utilise postgreSQL, tu peux utiliser les vues (matérialisées ou pas) pour ça…

Pour la partie Runtime c’est exclusivement RocksDB, ce dont tu parles c’est l’archive à côté que nous pourrons utiliser pour la partie client.

1 « J'aime »

Porter la durée à 3 mois et introduire cette action supplémentaire, je pense que c’est bien. A voir s’il y a d’autres avis.

Quel est l’intérêt de cette durée concrètement ? Je veux dire, une certification se périme au bout de deux ans. Est-ce que ça ne suffit pas ?

C’est pour les certifieurs des étourdis : au moins en attendant 2 mois (ou 3 dans le dernier message de matograine) alors le certifieur est sûr et certain que l’étourdi ne retrouvera pas son ancien compte, et donc qu’il ne pourra pas l’utiliser pour avoir deux comptes membres avec la complicité involontaire du certifieur, qui s’en trouverait dupé/abusé.

Il y a exactement le même problème avec les étourdis qui ont leurs 5 certifications d’un coup.

Une alternative ne serait-elle pas de permettre à un certifieur de révoquer la certification donnée ?

3 « J'aime »

Dans la pratique le temps moyen entre 2 blocs est extrêmement sur Polkadot et Kusama, et tous les délais dans leurs protocoles sont gérés en nombre de blocs, on fait d’ailleurs de même chez Moonbeam.

Je pense donc au contraire qu’il est plus pertinent de gérer les délais d’expiration en nombre de bloc, car des crypto monnaies très utilisées et avec forte charge montrent que ça fonctionne dans la pratique, malgré les très fortes incitations économiques à essayer de manipuler le temps entre 2 blocs (notamment pour manipuler le staking ou les applications de lending/borrowing).

Les consensus sans PoW permette justement d’avoir un temps moyen entre 2 blocs enfin fiable, la pratique montre à minima que c’est le cas pour BABE/GRANDPA.

3 « J'aime »

Si c’est confirmé dans la pratique, alors pourquoi pas. De toute façon on pourra très bien changer le comportement s’il en était besoin.