DataJune est encore assez jeune et ne dispose pas de tests unitaires, les données présentées ici doivent être prises avec précaution
En essayant de répondre à @tuxmain sur le sujet La règle sur la limite des 100 certifications émises à faire évoluer, je me suis rendu compte que certains membres avaient atteint plus de 100 certifications émises (101 et 102) au cours de l’histoire de la Ğ1. Ci-dessous notre échange que je rends public si certaines personnes veulent creuser de leur côté.
Bonne idée, je vais ajouter ça.
Ça m’a fait remarquer qu’en corrigeant un bug silencieux sur l’expiration des certifications, j’avais causé une régression qui conduisait à ignorer l’expiration des certifs… Faudrait vraiment que je prenne le temps de faire des tests unitaires, parce que c’est con de se retrouver là.
Enfin bon, en affichant le outdegree maximal au cours du temps, je me suis aperçu qu’il passait quelques fois au dessus de 100 :
Soit c’est un bug de plus de DataJune, soit c’est un bug de Duniter. Saurais-tu me dire laquelle de ces 101 certifications est de trop ? De mon côté, je regarderai plus tard.
Il faut que j’implémente l’expiration des certifs dans gexplore, mais comme il faut que ce soit réversible c’est compliqué. (je me souviens que pour GVA il y avait plein de subtilités qui apparaissaient au moment de coder)
Ok, je vais passer ce message en public pour voir si d’autres personnes veulent investiguer en attendant que j’aie le temps de creuser pour voir s’il n’y a pas un bug dans DataJune.
Voici la liste des 119 certifications émises par Pi vers ces personnes et la date. Pour rappel, je m’intéresse au jour 950, c’est-à-dire le 2019-10-13.
Si les certifications vers des identités révoquées disparaissent, alors il faut que je le prenne en compte dans DataJune. Mais est-ce le cas ? J’ai toujours du mal à comprendre les ENTRY.stock, GLOBAL_CINDEX, [expired_on=0] et compagnie du protocole. Heureusement avec la v2 on aura des tests cucumbers lisibles par des humains
J’ai déplacé la conversation qui dérivait vers la manière de décrire un protocole, et je repose ma question initiale :
Pourquoi y a-t-il des identités ayant plus de 100 certifications émises ? Il y a probablement un problème dans DataJune mais je n’ai pas compris où. Est-ce que les certifications vers des identités révoquées comptent dans le stock ?
GLOBAL_CINDEX[issuer=ENTRY.issuer] : ce sont les entrées d’index liées à des certifications émises par ENTRY.issuer. Le plus souvent ce sont des certifications, parfois des mises à jour de données des certifications (par exemple, faire expirer une certification est une entrée d’index UPDATE qui met le champ expired_on à une valeur positive.
REDUCE_BY(GLOBAL_CINDEX[issuer=ENTRY.issuer], 'receiver', 'created_on') : on réduit les entrées en les réduisant par receiver et created_on (le blockstamp). Cette opération revient à avoir une liste de certifications avec leur état à l’instant t. Cette notion de réduction est capitale et omniprésente dans Duniter v1. Il faut bien comprendre que les index sont une liste de changements d’états, et que pour obtenir une entité (genre une certification au sein du CINDEX) il faut réduire par une clé faisant sens. Ici, une certification est représentée de façon unique par la clé “issuer + receiver + created_on”. D’où cette réduction.
N.B. : je note que dans le code de Duniter v1 “created_on” n’est pas utilisé, d’ailleurs je n’en voyais pas non plus l’intérêt en te l’expliquant car issuer + receiver est déjà suffisamment unique pour lister les certifications de façon unique, rejeux inclus.
[expired_on=0] : exprime que l’on veut filtrer, dans cette réduction (donc, la liste des certifications) pour ne conserver que celles ayant un champ expired_on à zéro, c-à-d n’ayant pas expiré. En effet, une certification expirée ne devrait pas être comptée dans le stock.
COUNT : compte le nombre de certifications résultantes.
Et donc quelques pistes pour DataJune :
peut-être comptes-tu les certifications expirées, ou que tu les comptes à un moment différente de Duniter v1 ;
peut-être comptes-tu les rejeux de certifications comme 2 certifs
@HugoTrentesaux Je viens de regarder le code, et pense avoir trouvé : tu fais expirer les certifications cert_validity après le temps du bloc où la certification est appliquée, pas après le temps du bloc où elles ont été signées (le numéro de ce bloc est dans le contenu de la certif). Du coup, elles ont une durée de vie un peu trop longue…
Je me suis dit que j’allais corriger ce bug facilement en remplaçant les temps par des numéros de bloc avec une durée de certification égale à 2 ans / 5 min, (durée d’une certification / temps cible entre deux blocs).
Mais je me suis rappelé qu’on s’écartait pas mal de ce temps cible de 5 minutes :
Ça veut dire qu’il faut que j’implémente une solution propre quand même
[edit 2] non, en fait je me rends compte que la durée d’une année était de 365.25 jours et pas 365. Voilà un deuxième facteur d’erreur. Et c’est évidemment pire avec une durée de certification plus longue
DataJune est encore assez jeune et ne dispose pas de tests unitaires, les données présentées ici doivent être prises avec précaution
En essayant de répondre à @tuxmain sur le sujet La règle sur la limite des 100 certifications émises à faire évoluer, je me suis rendu compte que certains membres avaient atteint plus de 100 certifications émises (101 et 102) au cours de l’histoire de la Ğ1. Ci-dessous notre échange que je rends public si certaines personnes veulent creuser de leur côté.
: tu fais expirer les certifications cert_validity après le temps du bloc où la certification est appliquée, pas après le temps du bloc où elles ont été signées (le numéro de ce bloc est dans le contenu de la certif). Du coup, elles ont une durée de vie un peu trop longue…
