Étude d'impact d'attaques Sybil V5 - Stratégie d'attaque plus rapide!

Oui, il faut aller plus loin et inclure le paramètre sigPeriod. Aujourd’hui, on a une croissance potentielle de sybille sans réaction de la communauté. L’élément sigPeriod est là pour laisser à la communauté le temps de réagir : ce qu’il convient donc de regarder c’est :

  • Quelle taille l’infection peut prendre avant que la communauté ne puisse réagir
  • Est-ce que l’infection a le temps de dépasser la communauté et donc de détruire la monnaie

Ce deuxième point est compliqué à mesurer, il est directement facteur de la croissance de la communauté. Croissance qui est elle-même limitée par le sigPeriod…

Non, la croissance de la communauté peut être parfaitement nulle, et selon sa taille une attaque donnée n’aura pas la même vitesse relative de propagation.

Tout à fait, je souhaitais juste montrer la rétroaction de sigPeriod sur tout les éléments analysés ici. Tu as bien fait de preciser mon analyse qui montrait juste l’aspect croissance.

Parfait cette fois-ci nous sommes sur la même longueur d’onde @cgeek. Ta dernière formule est identique a la mienne à un facteur près : le nombre de certifications que possèdent les attaquants au lancement de l’attaque, je suppose qu’ils en ont (S-Q) quand tu suppose qu’il les ont encore toutes S. Pour les résultats 126 et 168 en fait nous avons tout les deux raisons. 168 est le bon résultat si les attaquants partent avec S certifications et 126 le bon résultat si les attaquants partent avec S-Q certifications.

Et par exemple 50.000 noeuds de 50.000 membres sybil ? C’est hélas assez facile a réaliser pour quelqu’un qui à des moyens en monnaie-dette…

Stéphane, pour la 1ère fois depuis que je te lit, je pense que tu te trompe. La question de la sécurité de la WoT face aux attaques sybil est une question qui concerne directement le cœur de Duniter, c’est maintenant que nous devons réfléchir et mettre en place des mesures de protections efficaces.

Cette mesure est évidemment nécessaire mais pas suffisante. L’attaque sybil continue de progresser longtemps après que les attaquants d’origine ne soient plus membres et amène dans de nombreux cas à une destruction inévitable de la monnaie.

Merci @Inso tu vise juste. La survie de la monnaie dépend effectivement d’un rapport entre la croissance de la communauté légitime et la croissance de l’infection sybil. Ce 2ème point est effectivement compliqué à mesurer, mais après une intense réflexion je crois avoir réussi a le simuler !

@cgeek @Inso Ça y ai j’ai intégrer le paramètre sigPeriod dans mon tableur de simulation. Et j’ai une mauvaise nouvelle : il y a un aspect que personne d’entre nous n’avais prédit, si sigPeriod limite effectivement la croissance de la région sybil, il limite tout autant sa décroissance.
En effet, même lorsque les auteurs de l’attaque ne sont plus membres, les comptes sybil qu’ils ont créer vont eux rester membres jusqu’à l’expiration de leur membership, or un sigPeriod élevé provoque un différé important entre l’adhésion des attaquants et l’adhésions des sybil créer de cycles en cycles, a tel point que l’attaque sybil peut continuer (et même s’intensifier) des années après que les auteurs ne soient plus membres !!

Exemple de simulation comparants 4 valeurs différentes de sigPeriod :
3j/jaune, 5j/bleu, 6j/orange, 7j/vert


Ici seul sigPeriod varie, les paramètres monétaires choisies sont indiqué dans le tableau de la photo. Pour être le plus proche possible de la situation réelle, je calcule désormais l’évolution jours par jours sur 10.000 jours !! (28ans)
1er constat : la valeur de sigPeriod a en réalité très peu d’impact sur l’ampleur de l’attaque sybil.

Pour avoir une bonne idée des paramètres monétaires les plus résistants aux attaques sibyl, il faudrait refaire la simulation avec beaucoup de paramètres différents. Et c’est là que j’ai besoin de votre aide, mon ordi manque vraiment de puissance et le tableur devient lourd et lent. J’invite ceux qui ont un ordi un peu plus puissant à tester plusieurs jeux de paramètres et publier les graphes.

C’est très facile, vous avez juste à changer les valeurs du tableur de la feuille params :slight_smile:

L’intégration de sigPeriod m’a révéler que le paramètre msValidity joue en rôle important dans l’impact de l’attaque. La preuve avec le même graphe que tout a l’heure mais un msValidity plus court (1ans au lieu de 2) :


l’impact de l’attaque est déjà beaucoup plus faible, et surprise, un sigPeriod faible (2j/vert) nous protège mieux qu’un sigPeriod plus élevé !

En conclusion :
Avant de figer dans le marbre les paramètres de notre 1ère monnaie de prod nous devons creuser davantage l’impact de chaque série de paramètre possible sur notre capacité de résistance aux attaques sybil.
L’outils est là, il ne vous reste plus qu’a télécharger le tableur et faire vos simulations :
Tableur dernière version (v4) : simu_impact_sybil_v4.ods (11,1 Mo)
(j’ai héberger le fichier sur mon serveur car il dépasse la taille max autorisée sur ce forum)

J’ai fait un petit programme de simulation de métastase sybil pour m’en assurer : sybils.js.

Celui-ci tente de créer le maximum de sybils possibles étant donné :

  • stepMax = 6
  • sigQty = 5
  • sigPeriod = 1 semaine
  • durée de simulation, sigStock et stepMalveillants variables

Voici les résultats bruts :

stepMalveillants = 5, durée 1 an(s), sigStock = 70,      53 sybils crées
stepMalveillants = 5, durée 1 an(s), sigStock = 100,     53 sybils crées
stepMalveillants = 5, durée 1 an(s), sigStock = 150,     53 sybils crées
stepMalveillants = 5, durée 2 an(s), sigStock = 70,      70 sybils crées
stepMalveillants = 5, durée 2 an(s), sigStock = 100,    100 sybils crées
stepMalveillants = 5, durée 2 an(s), sigStock = 150,    106 sybils crées
stepMalveillants = 5, durée 3 an(s), sigStock = 70,      70 sybils crées
stepMalveillants = 5, durée 3 an(s), sigStock = 100,    100 sybils crées
stepMalveillants = 5, durée 3 an(s), sigStock = 150,    150 sybils crées
stepMalveillants = 4, durée 1 an(s), sigStock = 70,     328 sybils crées
stepMalveillants = 4, durée 1 an(s), sigStock = 100,    328 sybils crées
stepMalveillants = 4, durée 1 an(s), sigStock = 150,    328 sybils crées
stepMalveillants = 4, durée 2 an(s), sigStock = 70,     931 sybils crées
stepMalveillants = 4, durée 2 an(s), sigStock = 100,   1207 sybils crées
stepMalveillants = 4, durée 2 an(s), sigStock = 150,   1219 sybils crées
stepMalveillants = 4, durée 3 an(s), sigStock = 70,    1048 sybils crées
stepMalveillants = 4, durée 3 an(s), sigStock = 100,   1927 sybils crées
stepMalveillants = 4, durée 3 an(s), sigStock = 150,   2647 sybils crées
stepMalveillants = 3, durée 1 an(s), sigStock = 70,    1261 sybils crées
stepMalveillants = 3, durée 1 an(s), sigStock = 100,   1261 sybils crées
stepMalveillants = 3, durée 1 an(s), sigStock = 150,   1261 sybils crées
stepMalveillants = 3, durée 2 an(s), sigStock = 70,    7786 sybils crées
stepMalveillants = 3, durée 2 an(s), sigStock = 100,   8916 sybils crées
stepMalveillants = 3, durée 2 an(s), sigStock = 150,   8930 sybils crées
stepMalveillants = 3, durée 3 an(s), sigStock = 70,   13818 sybils crées
stepMalveillants = 3, durée 3 an(s), sigStock = 100,  24314 sybils crées
stepMalveillants = 3, durée 3 an(s), sigStock = 150,  28925 sybils crées
stepMalveillants = 2, durée 1 an(s), sigStock = 70,    3576 sybils crées
stepMalveillants = 2, durée 1 an(s), sigStock = 100,   3576 sybils crées
stepMalveillants = 2, durée 1 an(s), sigStock = 150,   3576 sybils crées
stepMalveillants = 2, durée 2 an(s), sigStock = 70,   45586 sybils crées
stepMalveillants = 2, durée 2 an(s), sigStock = 100,  48578 sybils crées
stepMalveillants = 2, durée 2 an(s), sigStock = 150,  48592 sybils crées
stepMalveillants = 2, durée 3 an(s), sigStock = 70,  140880 sybils crées
stepMalveillants = 2, durée 3 an(s), sigStock = 100, 214740 sybils crées
stepMalveillants = 2, durée 3 an(s), sigStock = 150, 233865 sybils crées
stepMalveillants = 1, durée 1 an(s), sigStock = 70,    8055 sybils crées
stepMalveillants = 1, durée 1 an(s), sigStock = 100,   8055 sybils crées
stepMalveillants = 1, durée 1 an(s), sigStock = 150,   8055 sybils crées
stepMalveillants = 1, durée 2 an(s), sigStock = 70,  204168 sybils crées
stepMalveillants = 1, durée 2 an(s), sigStock = 100, 210072 sybils crées
stepMalveillants = 1, durée 2 an(s), sigStock = 150, 210086 sybils crées
stepMalveillants = 1, durée 3 an(s), sigStock = 70, 1079712 sybils crées
    JavaScript heap out of memory :)

Ce que je vois là, c’est qu’une attaque parfaite sur 3 années glissantes (le temps probable d’expiration d’une certification) est possible, mais ne dépasse pas les 2647 sybils tant que les attaquants ne disposent pas de plus de 2 steps pour créer les sybils.

2647 sybils ne me paraît pas insurmontable si l’on dispose de 10.000 utilisateurs et 3 années d’action, il est possible d’inciter les utilisateurs à protéger leur monnaie en installant un nœud notamment.

Par ailleurs, j’ai oublié qu’il existait aussi la possibilité aux utilisateurs d’agir directement sur la distance aux attaquants en augmentant celle-ci, afin de contenir l’attaque.

Je vais en parler sur l’autre sujet …

J’ai lu votre argumentaire comme un roman de science fiction. Très intéressant !

Je ne saurais pas vous aider je crois, mais je vous encourage à continuer. :slight_smile:

@cgeek. Merci pour ce script que j’ai analyser avec attention et que j’ai également exécuter sur ma machine :slight_smile:

En soi il n’est pas faux, mais il simule une méthode de propagation des comptes sybil qui de (1) est loin d’être la plus rapide de (2) ne permet pas un remplissage optimal de l’espace disponible pour les attaquants.

Je me suis rendu compte il y a quelques jours, que la méthode de propagation que je simule (couche par couche) n’est pas la plus rapide. J’ai donc travailler sur une nouvelle version de mon tableur qui simule une stratégie de propagation bien plus efficace.
Explications en image avec un exemple concret :
S=sigStock=9, Q=sigQty=3 et n=stepMax-stepAttackers=3
La couleur des comptes sybil représente leur distance aux attaquants de départ. Rouge=1, Orange=2, Marron=3.

A gauche la méthode v4 et à droite la méthode v5 !
Plutôt que de remplir la WoT de manière horizontale (couche par couche). Il est beaucoup plus efficace de remplir la WoT de manière verticale, c’est a dire en formant un groupe émetteur le plus tôt possible en utilisant les comptes disponibles de toutes les couches.
Ce que j’appelle les groupe émetteurs (entourés en bleu) se sont les groupes de Q comptes sybil qui vont émettre une chaine de S nouveaux comptes sybil.
La distance entre la nouvelle chaîne produite et les attaquants de départ étant calculée par le plus court chemin possible, elle est égale à la distance du compte sybil émetteur le plus proche des attaquants additionnée de 1.

Dans mon tableur v5, j’ai agrder 2 simulations sur 4 en v4 pour comparer la différence entre ces 2 méthodes de propagation. Voici un exemple concret :


Les paramètres de la simulation sont tous indiquer sur la tableau de gauche, ici le seul paramètre qui varie est le taux de croissance de la communauté légitime :
Jaune/Orange : +0,08%/jour = +33,9%/ans !
Bleu/Vert : +0,14%/jour = +66,6%/ans !
On observe toujours, et ça semble intuitifs, que plus la communauté légitime croit vite, moins l’attaque sybil à d’impact. Et donc la vitesse de propagation de la région sybil est un facteur déterminant de l’impact de l’attaque. Observez la différence entre les courbes bleu et verte, pour lesquelles seule la stratégie de propagation change !

Tableur dernière version (v5) : simu_impact_sybil_v5.ods (11,0 Mo)

@cgeek avec ma nouvelle méthode de propagation j’obtiens pour les mêmes paramètres :
stepMalveillants = 4, durée 1 an(s), sigStock = 150, 4650 sybils crées (taille maximale)
stepMalveillants = 4, durée 2 an(s), sigStock = 150, 4650 sybils crées
stepMalveillants = 4, durée 3 an(s), sigStock = 150, 4650 sybils crées
Et j’attend les paliers que tu indique au bout de :
328 sybils en 26 semaines.
1219 sybils en 33 semaines.
Et la taille max (4650) est atteinte en seulement 40 semaines !

De ce que j’en est lu du code, ta méthode de propagation des comptes sybil est encore différente mais elle n’est pas la plus rapide ET je pense même qu’elle ne permet pas d’optimiser l’espace disponible et que si tu fait un test sur plus longue durée tu n’attend pas la taille max.
En effet, j’ai exécuter ton script pour des durées plus longues et j’obtient :

stepMalveillants = 4, durée 2 an(s), sigStock = 150, 1219 sybils crées
stepMalveillants = 4, durée 3 an(s), sigStock = 150, 2647 sybils crées
stepMalveillants = 4, durée 4 an(s), sigStock = 150, 3866 sybils crées
stepMalveillants = 4, durée 5 an(s), sigStock = 150, 4524 sybils crées
stepMalveillants = 4, durée 6 an(s), sigStock = 150, 4648 sybils crées
stepMalveillants = 4, durée 7 an(s), sigStock = 150, 4648 sybils crées
stepMalveillants = 4, durée 10 an(s), sigStock = 150, 4648 sybils crées

Soit 2 places perdu (4648 au lieu de 4650) pour 2 cycles. Bon en fait c’est faible, mais sur 3 ou 4 cycles l’erreur doit être beaucoup plus grande !

Aujorud’hui le Bitcoins compte 5000 noeuds pour environ 100.000 utilisateurs, soit un taux de 5% d’utilisateurs éxécutant un nœud à un instant t. (c’est certainement plus au total, car tout le monde n’exécute pas son nœud 24h/24, 7j/7).

Sur TestNet, je recense environ 30 nœuds membres dont une moyenne de 15 qui tournent en même temps, et encore je surestime la valeur. Or nous sommes actuellement 190 membres mais 42 ont expiré par oubli de renouvellement donc en réalité nous sommes autour de 230.
Mais même en prenans 190 ça ne fait que 7,9% de membres éxécutant un noeud en même temps alors que nous sommes principalement des testeurs et contributeurs.
Je suis certain que dans une monnaie de prod, le pourcentage de memrbes éxécutant un nœud en même temps sera plus faible que sur une monnaie de test, de l’ordre de 5%.
Ce qui veut dire que si une communauté sybil dépasse la taille de 5% des membres légitimes, alors elle prend le contrôle de la monnaie !

J’y ai penser. Mais les comptes sybil peuvent par exemple produire des chaines de (S-1) comptes et garder pour chaque groupe émetteur une certification pour se “rapprocher” de la communauté légitime. Existe t’il aujourd’hui dans Duniter la possibilité de refuser une certification reçue ?

1 Like

Je ne regarde toujours pas le détail de fond, car notamment les paramètres de l’hypothèse ne sont pas donnés (stepmax = ? … que signifie stepMalveillants ? etc.).

J’ai noté toutefois que sigSotck =150 était utilisé alors qu’il me semble que c’est un facteur qui doit justement être revu.

Avec des hypothèses clairement établies et des données acceptables, je regarderai le sujet en détail pour comprendre de quoi il s’agit véritablement.

Je ne suis pas sûr qu’on puisse comparer, notamment le nombre de mineurs au début du Bitcoin relativement à son nombre d’utilisateurs à l’époque était certainement bien plus élevé, on peut supposer qu’il n’y avait pratiquement que des mineurs au début. Donc les 5% d’aujourd’hui sont plus un rythme de croisière qu’autre chose. D’ailleurs ce nombre diminue continuellement.

Le remplissage horizontal est fait pour remplir au maximum chaque couche étant donné la règle de distance.

Si tu remplis verticalement tu n’optimises pas les distances, mais tu maximises la vitesse de remplissage. Donc tu auras moins de sybils au total. C’est un choix d’attaque.

Non ça ne fonctionne pas, la distance est unidirectionnelle. Les sybils ne peuvent pas forcer la distance de quelqu’un vis-à-vis d’eux.

ok, donc tu pense qu’on sera suffisamment nombreux à tourner un nœud en début de monnaie (moment ou elle est plus fragile) ? J’espère que oui, mais le fait de ne voir que 10 à 15 noeuds membres connecter en même temps sur 200 utilisateurs ça m’inquiète, j’espère que nous seront une proportion plus élevé de membres a tourner un nœud lors de la 1ère vrai monnaie de prod.

Ok, effectivement la région sybil créer sera plus petite. Mais ce qui compte pour l’attaquant c’est d’arriver à croître plus vite que la communauté pour prendre le pas sur elle. Je n’arrive pas à calculer la taille finale de la région sybil avec cette autre stratégie d’attaque, j’ai essayer d’adapter ton script sybil.js avec une stratégie de propagation verticale pour qu’il me donne la réponse mais je n’ai pas réussi…

Heu alors là je ne comprend pas, ou alors tu à mal compris mon propos.
Supposons que toi et moi soyons a une distance de 3 l’un de l’autre. Si je certifie un nouvel entrant il sera a une distance de 4 de toi. Mais si je te certifie avant de certifier ce nouvel entrant, alors ce nouvel entrant sera à une distance de 2 de toi au lieu de 4.
Donc de la même manière, les comptes sybil des couches intermédiaires peuvent très bien certifier des membres de la communauté pour que les comptes sybil des couches supérieures soient moins loin (donc plus proches).
Aujourd’hui dans Duniter, quand je reçoit une certification je n’ai aucun moyen de la refuser. Ils erait intéressant de faire en sorte qu’un membre puisse refuser une certification qu’il reçoit. Pour éviter que des comptes sybil certifient des cmptes légitimes pour optimiser leurs distances ou pour eêtre plus difficile à détecter.
En effet, j’en parlais avec Cesar l’autre soir, les ,algos de détection des régions sybil se basent sur le fait que al région sybil à peu de connections avec le reste de la communauté (en théorie Q connexiosn seulement s’il y a Q attaquants). Mais si les comptes sybil certifient ça et la des membres sybil cela peut empêcher les algos de détection de fonctionner. Et peut aussi augmenter la taille de la région sybil en diminuant les distances des futurs comptes sybil.
Est-ce plus clair dit comme ça ?

@Galuel, tu parle du script de Cédric ou de mon tableur de simulation ?

Dans les 2 cas, sigStock n’est qu’un paramètre réglable à l’entrée. Mes dernières simulations utilisent justement la valeur de sigStock que tu recommande (autour de 73).

Quand au paramètre stepMalveillants, que j’ai renommer stepAttackers pour éviter le franglish, je l’ai définie au début de mon 1er post :

C’est vrai que j’aurais pu être plus clair. stepAttackers est plus précisément la distance maximale entre tout attaquant et tout membre point de contrôle au lancement de l’attaque.

Je ne sais pas, mais si tu t’inquiètes de tout tu risques la paralysie. Par exemple je notes que tu ne tiens pas compte du cas où un météore vient frapper directement la tête des nœuds légitimes, créant de fait une situation où les sybils seraient en surnombre.

Tu me diras “oui mais c’est un cas peu probable”, et moi je te demanderais “où est la limite entre ce qui est probable et ce qui ne l’est pas ?”. Et alors tu verras qu’on ne peut pas trancher ce point.

Donc, il y a un moment où il faut prendre le risque, sinon on n’avance pas du tout.

De plus, il y a quand même de bonnes raisons de penser que les 1ers inscrits seront aussi des personnes investies et qui comprendront les enjeux du fait d’ajouter un nœud au réseau, ou a minima de se tenir en alerte. Donc qu’on pourra compter sur elles pour réagir en cas de besoin.

Mais je ne peux pas te garantir que tout ira bien ! Aucun algorithme, aussi efficace soit-il, ne le peut.

Non, regardes :

Toi <-- Gus1 <-- Gus2 <-- Moi

Tu es à une distance de 3 de moi. Si tu signes un sybil, et que tu me signes, voici la situation :

Sybil <-- Toi <-- Gus1 <-- Gus2 <-- Moi
           `-------------------------^

Le sybil est toujours à une distance 4 de moi (partant de moi, c’est la définition de la distance). Celle-ci est bien unidirectionnelle et ne peut être forcée par les attaquants.

Du coup il n’y a aucun besoin de pouvoir refuser des certifications, ni de s’inquiéter que les sybils puissent nous certifier.

2 Likes

Non, comme l’a expliqué cgeek la distance est unidirectionnelle.

Comment ça se passe dans le cas suivant ?

    |------v
Sybil <-- Toi <-- Gus1 <-- Moi
           `----------------^

Le sybil est à 3 pas de toi, et tu es à 2 pas du sybil. Qui prend le dessus ? Notamment, si la distance entre toi et le sybil augmente, qui est exclu ? Le premier qui renouvelle ?

Règle : 90%

La règle est symétrique : je dois tout autant être proche de la sybil qu’elle de moi.

La règle de distance s’applique à chaque adhésion ou renouvellement. Donc si au moment où je tente de me renouveler je suis trop distant de la sybil, alors je ne respecte pas moi-même la règle de distance.

C’est notamment pour cela qu’on a le paramètre xpercent: si un groupe fait en sorte d’être point de contrôle (il émet pas mal de certifications) mais de façon bien dense pour créer peu de chemins, mais de façon a activer la distance, alors il pourrait exclure la toile légitime au bout d’un certain temps.

D’où le fait que la règle de distance ne s’applique pas à 100% des membres, car certains n’émettent aucune certif, mais encore moins à 100% des points de contrôle.

Pour que les certifications des sybil prennent le dessus, il est donc nécessaire que les sybils passent en surnombre par rapport aux points de contrôles honnêtes de la toile.

En conséquence, plus il y a de sybilles, plus les utilisateurs honnêtes doivent émettre de certifications pour rester point de contrôle (sinon ils seront exclus par la règle qui défini qui est un point de contrôle)

A voir les impacts que ça vous inspire, pour l’instant ça me laisse songeur. Je me demande comment mesurer ça (ça devient complexe cette analyse).

2 Likes

Il est intéressant de prendre le problème dans l’autre sens (principe de symétrie) : étant donnée une WoT de sybils, comment des utilisateurs humains pourraient renverser la toile de faux, par une toile correcte ? Comment s’y prendraient-ils, comment y arriveraient-ils, en combien de temps ?

Voici la courbe qui définit le nombre de certifications à émettre pour être point de contrôle en fonction de N :

Comme tu peux le voir :

  • pour 10 membres il en suffit d’une certification
  • pour 100 membres 2
  • pour 1.000 membres 4
  • pour 10.000 membres 6

C’est en fait assez facile à obtenir comme statut, il y a potentiellement beaucoup de points de contrôle dans la toile, de sa naissance à sa vie adulte.

Merci c’est ce que j’avais besoin d’entendre, je suis sans doute trop parano. Mais j’ai tellement été habitué à notre inéluctable asservissement à l’oligarchie financière qu’une part de mon esprit se refuse à croire que nous allons réussir a faire ce que l’on ai en train de faire !

Quoi qu’il en soit, comme tu dit à un moment ou à un autre il faut bien prendre le risque d’agir, on ne pourra pas tout prévoir !

Je m’étais fixer dans la tête, que la distance entre 2 membre était défini comme le plus court chemin entre eux, sans tenir compte du sens des certifications. C’est pour cela que je ne comprenais pas.

Il y tout de même un autre argument (enfin plusieurs même), qui me font penser que toute certification devrait être signée par le “receveur” avant de devenir effective :

  1. pour faciliter la détection des régions sybil par les algos de détection.
    En effet, l’algo se base sur le fait qu’il y a peu de liens entre la région sybil et la région légitime et que donc en traçant beaucoup de chemins aléatoires d’une longueur de log N, les chances de tracer un chemin qui relie les deux régions sont quasi nulles.
    Si les sybil peuvent nous certifier librement, ils auront intérêt à le faire au moins pour être plus difficilement détectable par les algos et donc avoir plus de temps devant eux avant que la communauté légitime ne réagisse.

2/ Si quelqu’un me certifie, c’est que je le connais. La WoT ayant aussi pour rôle de créer et maintenir une confiance entre les membres du réseau. Je trouve logique et normal qu’une certification doivent également être validée/signée par le receveur. je n’ai pas envie que n’importe quel inconnu puisse me certifier.

3/ Pour une question de réputation. Si un membre qui ma certifier est ensuite condamner par la justice ou/et par le reste de la communauté pour non respect des règles ou pour tout autre raison. La mauvaise réputation de cette personne vas dépeindre sur les membre qu’elle à certifier.
le fait de devoir signé toute certification reçu pour qu’elle devienne effective, permet de dire, ok j’ai confiance en la personne qui m’a certifier.

2 Likes

Il est toujours possible de réaliser la certification dans l’autre sens alors, certifier en retour celui qui t’a certifié, afin que la reconnaissance devienne symétrique.

2 Likes