Je vais passer ma journée, et peut-être même plusieurs de suite, à la simulation de ces réflexions. Je vais prendre uniquement les 2 cas qui nous intéressent dans un 1er temps (stepmax = 5 et 6), ce qui aidera déjà beaucoup à nous orienter.
Une remarque toutefois sur sigQty : il faut se rappeler que cette valeur est concurrencée par stepMax qui implique par elle-même un nombre de signatures minimales. Ainsi il ne faut pas croire que sigQty signatures sont nécessairement suffisantes à faire entrer un membre pour tout t. La barrière à l’entrée est dynamique, mais bornée à sigQty au minimum.
Pour comprendre un raisonnement avec beaucoup de paramètres comme ici, il convient de choisir des valeurs faibles, mais pas trop, afin de réaliser une analyse simplifiée. Par exemple stepmax = 3, un max de signatures de 10 etc… ce qui est suffisant pour démontrer le cas simple, et généralement suffisant aussi pour généraliser ensuite avec des valeurs quelconques.
Autre chose : techniquement Duniter n’oblige pas, étant donné sigPeriod = 1 semaine, de devoir faire 1 opération par semaine pendant 6 semaines pour émettre 6 certifications. Au contraire il est possible de les émettre simultanément puis celles-ci seront inscrites en blockchain au rythme de 1 par semaine. La limite à ce mécanisme étant de sigWindow (durée de péremption d’une certification hors blockchain).
D’ailleurs, cela facilite la possibilité d’intégrer des membres dès lors que leur dossier est complet, sans déranger les autres.
Et donc ce sont les robots qui bossent, pas les humains.
Bon, suite aux discussions sur le salon XMPP et aux simulations à petite échelle que j’ai pu faire sur papier, je constate que tant qu’on a sigQty << sigStock, alors la toile peut se débrouiller pour s’étendre et se maintenir de façon rapide.
Donc je m’arrête là pour les simulations, rien n’empêche ceux qui veulent de la reprendre ou la continuer, il y a certainement des choses intéressantes à en tirer.
Cela ne change par contre rien à mon affaire de choix de valeur pour (stepMax, sigQty), dont je remets ici les valeur pour mémo :
Je note que, si le million est un minimum visé, on ne peut pas conserver (5,5). Reste donc soit à utiliser une distance de 6, soit à garder la distance de 5 mais accepter des membres avec seulement 4 signatures.
Suite au split je reposte ici la partie de mon message qui ne concerne pas le split :
S’il est vrai qu’un humain connait bien 50 autres humains en moyenne, il me semble qu’il nous faut considérer le fait qu’une proportion des connaissances de chacun (disons 20%) resterons toute leur existence réticents à l’adoption d’une monnaie libre soit par peur du changement ou parce qu’ils sont beaucoup trop conditionné ou pour toute autre Ğraison que l’on ne peut ni prévoir ni juger.
J’ai donc refait les calculs en considérant que sur le long terme 80% des connaissances de chacun adoptera la monnaie libre, ce qui reviens a prendre 40 comme nombre moyens de personnes certifiées par un membre et non 50 :
50 connaissances est lié aux capacités de mémoire et aux interactions sociales. Des hommes adoptant une monnaie libre seront naturellement dans un environnement d’hommes souhaitant adopter une monnaie libre, adapteront leurs connaissances (qui ne sont pas figées, mais évoluent dans le temps) vers des hommes souhaitant adopter une monnaie libre. Donc de ce point de vue l’hypothèse ne tient pas, elle ne prend pas en compte l’adapation(t), le flux(t), les connaissances(t).
Par ailleurs le nombre de 50 est issu des connaissances sociales actuelles qui sont établies sur la base d’une société évoluant au sein d’une monnaie non-libre, il est tout à fait possible que ce nombre aussi évolue. Ces réflexions ne sont là que pour évaluer “à peu près” ce qu’il est “raisonnable” d’envisager, mais ne préjuge absolument pas du résultat final (sauf WoT max qui est bien une limite supérieure).
Concernant la propriété d’être sentry : Cela permet d’avoir un contrôle sur la distance de la Toile, mais cela joue aussi à l’inverse sur le blocage de son expansion.
Ainsi si un Sybil certifie Y[N] il devient centre de contrôle, mais c’est gênant en soi. Car il va de ce fait par exemple certifier d’autres sybils, qui deviendront centre de contrôle en certifiant, ce qui de l’autre côté de la toile, va limiter son expansion pour de mauvaises raisons.
Qui plus est cette notion plus forte permet d’éliminer le paramètre “90% des sentries” on peut se baser sur 100%, ce qui est plus complet.
Là il convient donc de symétriser la notion :
Devient Sentry le membre qui non-seulement a émis au moins Y[N] certifications, mais aussi est certifié par Y[N] membres. Ce qui rend le contrôle plus fort tout en éliminant les blocages Sybils (car un Sybil peut en effet soit risquer une expansion incontrôlable, mais aussi bloquer le développement pour de mauvaises raisons du côté de la toile où il ne joue pas (puisqu’il devient sentry non-légitime…)).
Ainsi un Sybil qui émet plein de certifications uniquement est dans la même situation que précédemment, son expansion sera limitée par la distance, mais il ne bloquera pas en plus les autres, car n’ayant pas reçu Y[N] certifications lui-même, il n’est pas pris en compte dans le calcul de distance.
Par ailleurs je pense que la formulation Y[N] = partie entière (N^(1/stepmax) + 1) me semble un poil mieux que la partie entière seulement. Avec un stock de 80 certicifications ou plus ça ne change pas grand chose, mais c’est un meilleur contrôle. Notamment cela permet d’être sentry avec une WoT de 3 membres et un stepmax de 2 (Y[N] = 2). Ce n’est par contre pas aussi fondamental que la question sur la symétrie concernant Y[N].
Oui mais cela donne, à l’inverse, un grand pouvoir aux Sybils puisqu’ils seront pris systématiquement en compte dans la distance. Et donc en cas de certifications en cercle pseudo-fermé, les Sybils auraient un grand pouvoir sur l’expansion par blocage minoritaire (1% suffit).
Avec un %sentries de l’ordre de 80% à 90%, on s’assure au moins que si l’on a 20% à 10% de Sybils sentries, celles-ci ne pourront pas verrouiller l’expansion de la toile.
Pour le reste, je suis plutôt d’accord : on a vu que certifier des personnes qui sont elles-mêmes de forts certificateurs resserrait, rapprochait la toile, créait des chemins vers de nombreuses personnes. Tandis que sans la symétrie, les chemins partant des sentries sont plus pauvres.
Oui j’y songeais aussi : à petite échelle ça permet de détendre la toile, tandis qu’à plus grande échelle ça ne change pas grand chose.
Bon … simplement j’espérais qu’on aurait pas de changement de protocole aussi important à cette étape. Mais bon, cela me semble nécessaire.
Exact, même si Y[N] certifications sont nécessaires, on peut imaginer Y[N] sybils qui le réalisent, donc ça limite mais ça ne bloquerait pas, il faut donc garder le paramètre %.
Ce serait bien pour les clients que Y[N] leur soit donné avec la formulation (ce qui est le pendant pour la WoT de la valeur du DU et de sa formule pour la monnaie).
Donc pour N = 27, on a Y[N] = 3. Mais pour N = 28, Y[N] = 4. La différence avec ce que tu suggères est minime, donc je considère qu’on est déjà sur ce mode.
Oui c’est bon. Il faudrait le donner en réponse dans l’API qui donne les paramètres pour être sûr. Ca signifie donc aussi que c’était 3 déjà et pas 2 donc avant 27 ? Ca veut dire donc que là avec 27 membres on est toujours à 3 !?
Ca signifie par ailleurs que si les sentry sont déjà à 3 à plus de 10% (100% - 90%), alors il ne peut pas y avoir de nouveaux entrants right ? Il faut donc que les sentries soient à 2 à 90% pour que ça puisse s’ouvrir !?
Il n’est pas nécessaire que 90% des sentries soient à 2. . Actuellement 2 sentries sur 14 (mententon et Pierre-Yves sont à 3 d’au moins 1 sentries, ce qui fait plus de 10%). Et pourtant certaines identités en demande d’adhésion sont bien à 3 de 100% des sentries, comme gerard94 par exemple !
En revanche oui bien vue pour la symétrie de Y[N], ça me semble nécessaire contre les sybil effectivement
Oui la distance est bien relative à un individu, donc une sentry à 3 de distance pour I1 peut très bien être à 2 pour I2. Donc la toile n’est jamais absolument bloquée.
