Dans le sujet Pendant combien de temps doit-on conserver une évaluation de la règle de distance? je suis gêné par le mécanisme d’antispam temporel. Actuellement quand on demande une évaluation, une partie de monnaie est réservée, et au moment du résultat elle peut être libérée (unreserved) ou confisquée (slashed). Et on peut réitérer une demande d’évaluation pour une identité au moment où IdentityDistanceStatus est vidé (actuellement jamais, mais au minimum un intervalle de calcul de distance soit une session pour l’instant).
Donc il n’y a pas de pénalité autre que le coût de l’extrinsic à demander régulièrement une évaluation de la règle de distance alors que la limite est différente de celle de la blockchain car il s’agit de MAX_EVALUATIONS_PER_SESSION et que le calcul est hors chaîne.
Est-ce qu’il ne suffirait pas de mettre un coût franchement plus élevé à l’extrinsic pour “dissuader” un comportement de spam ? Et comme ça on pourrait se passer d’antispam temporel (limitation en fréquence) qui nécessite une certaine complexité du storage ?
En tout cas l’antispam temporel en cas d’évaluation positive était la protection de Duniter v1 avec msPeriod. Mais Duniter v1 était aveugle de l’évaluation négative, qui polluait les nœuds.
Donc oui pour moi le problème survient surtout pour la forme positive sur Duniter v2.
Par rapport aux frais élevés : soit l’évaluation est demandée par un tiers qui peut avancer les frais, soit les gens vont se plaindre qu’ils n’ont pas assez de G1 pour payer le droit d’entrée, malgré toutes nos explications.
Déjà qu’il faut se faire prêter au moins 10 G1 (1 DU) pour devenir membre quand on n’en a pas encore…
Après ça peut être volontaire pour pousser à échanger plutôt que d’attendre le DU, mais alors ça se discute avec la communauté.
Ou alors : l’évaluation de la distance est gratuite une et une seule fois par compte Unvalidated, qui doit l’émettre lui-même (et sous réserve d’avoir déjà passé la règle des N certifications). Les fois suivantes, réalisées soi-même ou par un tiers, resteront payantes au prix fort.
La limite est MAX_EVALUATIONS_PER_SESSION, soit actuellement 600 évaluations par heure.
Les voies de remplissage possible de cette limite sont :
un membre appelle request_distance_evaluation_for pour 600 identités Unvalidated qui ont 5 certifications mais ne respectent pas la distance, dans ce cas il doit avoir 600 fois EvaluationPrice en réserve et se les fera confisquer (6000 Ğ1 avec le réglage actuel)
un membre appelle request_distance_evaluation_for pour 600 identités Unvalidated qui ont 5 certifications et respectent la distance. Mais dans ce cas c’est le comportement attendu, ces identités seront validées, ce n’est pas du spam ><
600 membres appellent request_distance_evaluation pour eux même pour renouveler leur adhésion, et rien ne les empêche de le faire à chaque session
Donc pour moi, le plus risqué serait le troisième scénario (assez improbable) qui empêcherait de valider des membres légitimes.
On peut le gérer en empêchant d’appeler request_distance_evaluation pour soi-même si l’expiration de l’adhésion est trop loin dans le temps. Ça vous va si j’implémente ça ?
À propos de la limite par session : elle a été choisie au pif, on pourra faire des benchmarks sur les performances de l’oracle, l’empreinte dans le storage et le poids de l’inhérent d’application des résultats.