Le paramètre sigStock dont il est question ici a une influence sur l’ampleur des attaques sybil. Plus sigStock est grand plus une attaque sybil peut être massive, c’est pourquoi par sécurité il est bon de minimiser sigStock autant que possible.
Oui la preuve ici : Étude de la WoT
Personnellement j’avais signalé que 100 me semblais trop élevé, et qu’il faudrait diminuer a 80 voir 70.
L’avenir nous dira ce qu’il en est, nous devons suivre un maximum d’indicateurs sur la santé de la wot afin de pouvoir réagir et ajuster certains paramètres si l’on pense que cela peut consolider la wot.
En revanche, il ne me semble pas souhaitable de supprimer sigStock pour que la limite devienne de fait sigValidity / sigPeriod. Cela créer un couplage fort entre des paramètres qui ont des objectifs fonctionnels très différents.
Si a l’avenir on doit modifier sigValidity ou sigPeriod pour une raison X ou Y, on sera bien content que ça n’est pas d’impact direct sur sigStock, car cet impact pourrait etre contraire a l’effet souhaité.
Exemple : Pour une raison X ou Y on augmente sigValidity, ce qui rend l’engagement de certification plus fort et donne plus de poids a cet acte, qui sera donc moins fait a la légère, et qui consolide donc la toile. Si l’on a plus sigStock, on se retrouve avec un rapport sigValidity / sigPeriod qui augmente, ce qui fragilise la toile alors qu’on augmentais sigValidity pour la consolidée.
Ce n’est qu’un exemple pour montrer qu’il existe au moins 1 cas de future évolution possible des paramètres pour lequel un couplage fort serait nuisible.
Or, on ne peut pas déterminer toutes les Ğsituations a l’avenir et les décisions que nous ou nos prédécesseurs devront prendre en conséquence.
Afin d’être le plus robuste et souple possible, évitons au maximum les couplages que l’on peut éviter 