Pendant combien de temps doit-on conserver une évaluation de la règle de distance?

Nodes Duniter-v2s
1

Actuellement le résultat de l’évaluation de la règle de distance est stocké dans la map IdentityDistanceStatus qui à idty_index associe (requester_account_id, DistanceStatus) avec le statut qui peut valoir Pending, Valid, Invalid.
La seule utilisation du résultat de la règle de distance est d’appeler claim_membership ou renew_membership, et cela doit se faire automatiquement après, c’est l’objet de !219.
Donc a priori, pas besoin de stocker le résultat du calcul, le seul élément à stocker est le compte du demandeur pour la mécanique reserve/slash.
De plus DistanceStatusExpireOn est inutilisé (#164), et donc cette valeur n’est jamais retirée.

Souhaite-t-on conserver le résultat de la règle de distance pendant une certain durée ou peut-on adopter le fonctionnement suivant :

Les deux seules manière de demander l’évaluation sont :

  • request_distance_evaluation_for : on demande l’évaluation pour une autre identité dans le contexte de la validation d’identité
    • le compte demandeur doit être membre (est-ce nécessaire ?)
    • il ne doit pas y avoir de demande en cours pour l’identité cible
    • l’identité cible doit avoir le statut Unvalidated
  • request_distance_evaluation : on demande l’évaluation pour soi-même pour renouveler son adhésion (renew_membership) ou pour redevenir membre après expiration de l’adhésion (claim_membership)
    • le compte demandeur doit avoir le statut Member ou NotMember (est-ce nécessaire de la vérifier en amont ?)
    • il ne doit pas y avoir de demande en cours pour cette identité

Après une évaluation positive, si le statut est Unvalidated ou NotMember on appelle claim_membership, si le statut est Member on appelle renew_membership. D’où la nécessité de ne pouvoir demander l’évaluation de la règle de distance pour quelqu’un d’autre que dans le cas où il est Unvalidated.

Dans ce scénario, on pourrait quand même avoir besoin d’un mécanisme antispam car rien n’empêche les membres d’appeler request_distance_evaluation à chaque session. Si MAX_EVALUATIONS_PER_SESSION membres font ça, les pools d’évaluation seront toujours pleines, et aucune nouvelle évaluation ne pourra passer.

Donc en gros, pas besoin de conserver le résultat de la règle de distance, qui est immédiatement utilisé, mais on peut conserver une trace de la demande pour :

  • éviter d’avoir plusieurs demandes d’évaluation en cours pour une même identité
  • servir de mécanisme antispam en limitant la fréquence de demande d’évaluation pour une identité

Mais dans certains cas ce mécanisme antispam peut être gênant. Par exemple si on veut faire entrer quelqu’un dans la toile, que sa distance est tout juste ok au moment où on fait la demande, mais au moment où c’est évalué ça devient tout juste ko. Dans ce cas il faut attendre le délai antispam avant une nouvelle évaluation. On pourrait donc différencier le délai antispam en cas d’évaluation positive ou négative, mais ça devient franchement compliqué.

Voilà mes réflexions du jour, toute remarque est bonne à prendre et m’aide à avancer concrètement.

2

Effectivement. Et plus on réduit la période d’évaluation, plus le spam doit être fréquent pour être gênant puisqu’on augmente le nombre de créneaux disponibles.

3

Délai de zéro en cas d’évaluation négative, les frais restant dûs. C’est l’antispam classique de la blockchain donc ça me paraît correct.

2 Likes
4

Concrètement, ça donnerait :

  • une map PendingEvaluationRequests qui à idty_index associe account_id pour le mécanisme reserve/slash
  • une constante ValidEvaluationValidity en nombre de blocs pour définir la longévité d’une évaluation valide nécessaire au mécanisme antispam
  • une map ValidEvaluationResults qui à idty_index associe () (pour le mécanisme antispam sur les évaluations valides)
  • une map ValidEvaluationExpireOn qui à block_number associe Vec<IdtyIndex> pour vider la map précédente après ValidEvaluationValidity

Et ça réglerait le point que je soulevais dans la MR !105 pour éviter de stocker les account_id pour des évaluation valides alors que c’est uniquement pour des évaluations en cours que c’est nécessaire.

2 Likes
5

La situation est pas identique à celle d’un extrinsic classique, puisque le calcul de l’oracle n’est pas compté dans les poids. Il y a aussi un débit maximal d’évaluations, or les frais sont dimensionnés par rapport au remplissage du bloc, pas par rapport au débit d’évaluation (qui peut être saturé sans saturer le bloc).

6

Pour étalonner précisément l’extrinsic, je ne vois pas mieux que de réussir à sortir le calcul de distance de son oracle pour le mettre dans une palette de calcul, utilisée pour les benchmarks et réutilisée par l’oracle pour son calcul. Reste toutefois le coût de copie RPC qui ne sera pas identique.

Et de ré-étalonner cet extrinsic régulièrement.

7

L’intérêt de l’oracle est justement de ne pas consommer de ressources blockchain, le coût qu’on lui associe n’a pas à être lié à un étalonnage. Si on fait l’étalonnage des extrinsics, c’est avant tout pour être sûr de pouvoir produire le bloc à temps. Et si l’on utilise ce poids dans le calcul du coût, c’est pour éviter de créer une asymétrie entre les ressources que demande un extrinsic et son prix, mais ce choix peut être discuté.

On s’est posé la même question :smiley: