Étude de la WoT

J’ai pensé au fait que si on considère qu’une période de renouvellement annuel est minimale, et que l’on doit pouvoir signer jusqu’à 150 personnes max, alors on obtient forcément par la période entre deux signatures doit être au plus 365,25 / 150 = 2,43 jours.

Le même raisonnement implique qu’une période entre deux signatures de 7 jours, associée à un maximum de 150 signatures, implique forcément une période de renouvellement de 150 x 7 = 1050 jours = 2 ans 10 mois 20 jours, ce qui semble très long.

Et que donc il n’y a pas énormément de choix possible pour la période entre deux signatures…

2 Likes

Avec un tableur listant tout ces paramètres et des courbes montrant les impacts de leurs variations, j’imagine qu’on pourrait trouver les valeurs idéales, si elles existent ?

“idéal” ne signifie rien en soi. En faisant certaines hypothèses conformes à la réalité expérimentale, on peut limiter la variation des paramètres possibles, et envisager ce qu’une WoT maximale / WoT moyenne peut donner sous ces hypothèses. Le fait de considérer les hypothèses comme correctes restera sujet à discussion, tout autant que la forme de la WoT résultante visée.

Comme il y a en outre beaucoup de paramètres un graphe en 2D risque d’être très insuffisant, à moins de ne considérer que la variation de un ou deux paramètres, ce qui suppose d’avoir une idée bien fondée sur la fixation des autres.

Comme en outre la compréhension ne se diffuse pas d’elle-même, celui qui veut comprendre doit travailler le fond et proposer des formes.

D’après moi, les valeurs de ton premier post [quote=“Galuel, post:1, topic:977”]
maxstep = 4
sigSty = 4
Y[N] = N^(1/maxstep) = 42 (bon chiffre !)
N (max théorique) = Y[N]^maxstep = 3 111 696
sigStock = sigValidity / sigPeriod = Y[N] x sigSty = 168
sigPeriod = 1 semaine => sigValidity = Y[N] x sigSty x sigPeriod = 168 semaines = 3 ans + 3 mois
[/quote]

Me semblent être idéales. Sauf pour la sigPeriod, que je réduirais pour avoir un sigValidity de 1 an.
Le sigPeriod est là pour ralentir des attaques de robots. Une certification tout les 2,43 jours, c’est déja très bien et largement détectable en cas de tentative de métastase. Le sigValidity est là pour forcer le renouvellement régulier des reconnaissances entre individus. Le caler sur une période annuelle (le fameux “anniversaire” humain) me parait être idéal.

2 Likes

Ca me paraît insuffisant au vu de la suite des posts. Notamment en raison du fait que la WoT max théorique doit être bien supérieure à la WoT visée.

Par ailleurs, les posts suivants donnent des formulations plus précises en terme de relations entre les paramètres, et il faut une étude plus poussée et plus complète, comprenant des justifications expliquées pour se faire une idée plus juste.

Au vu de ce qui précède l’intuition me pousse à considérer un maxstep de l’ordre de 5 plutôt que de 4, et sans confirmation par d’autres de résultats approchants, de simulations plus complète, il est plus que déconseillé de prendre des résultats approximatifs comme source de valeurs valides.

De manière générale les considérations intuitives et textuelles (littéraires) ne sont pas une méthode scientifique valide.

Je me suis penché à nouveau sur le post#1 de cette discussion, et je pense que Y[N] reflète 2 réalités différentes et que cela pose problème dans le raisonnement. Pour rappel :

Note : on suppose ici sigQty = 1

Or si l’on considère qu’un individu est un point de contrôle car il aurait émis Y[N] certifications, d’une part cela ne signifie pas qu’il a atteint son stock maximal et peut donc en émettre plus (donc finalement on n’étudie pas le max), ou alors Y[N] = sigStock et alors on ne fait que parler d’un cas idéal mais expérimentalement peu fréquent où finalement les seuls points de contrôle seraient ceux ayant épuisé leur stock de certifications.

Et donc il faudrait peut-être différencier Y[N] “effet de levier maximal par individu” et Z[N] “nombre de certifications émises pour être un point de contrôle”, ce que je vais tenter de faire.

Il y a des points qui sont fondamentaux et sur lesquels on peut se fonder expérimentalement, qui permettent de cibler précisément :

  • sigStock = 150, nombre de connaissances moyennes = 50
  • 4 <= stepmax <=7
  • Une WoT moyenne acceptable est de taille (environ) N = 10⁶
  • sigQty doit être un nombre suffisant et est lié à la WoT(N) moyenne par : sigQty = 50/[N/(50+1)]^[1/(stepmax-1)]

Les couples de solution pour (stepmax,sigQty) sont alors déterminés (arrondis aux entiers) : (4,2), (5,5), (6,7) ou (7,10)

sigQty = 2 peut sans doute être éliminé car clairement trop faible. Ensuite stepmax = 7 semble quant à lui trop fort. Il nous reste donc (5,5) ou (6,7) comme valeurs acceptables. On comprend aussi que l’augmentation du stepmax est compensée en terme de contrôle par l’augmentation du nombre de signatures requises pour être membre.

La solution (5,5) me semble bonne, car elle propose un paramétrage symétrique. La distance max entre membres étant égale au nombre de signatures pour être membre, on pourrait dire “densité locale = rayon de la sphère”, ça tombe bien.

On a alors un très bon paramétrage suivant :

  • sigStock = 150
  • maxstep = 5
  • sigQty = 5
  • sigPeriod = 1 semaine => sigValidity (minimal) = sigPeriod x 150 = 2 ans et 6 mois (on peut prendre 3 ans + 3 mois + 3 jours tout aussi bien, ce qui évite l’habitude d’une date fixe, et puis signer chaque semaine à perpétuité pour valider en permanence ses 150 connaissances peut sembler fastidieux…)
  • WoT moyenne = (50+1)*(50 / 5)^5 = 5 100 000
  • WoT max = (150+1)*(150 / 5)^5 = 3,67 milliards ( = 720 x WoT moyenne)
  • Z[N] = 5 100 000 ^ (1/5) = 22

Je note qu’on obtient pour la WoT moyenne quelque chose qui semble proche d’une communauté économique optimale (qui rejoint la remarque que les petits pays sont plus souples que les gros, et ont de meilleurs résultats), et que la WoTmax n’est pas loin du total d’êtres humains actuel (2 fois moins à peine), ce qui me semble un bon signe de concordance avec la réalité expérimentale.

Ce qui me semble donc suffisant comme conclusion de l’étude. Tout paramétrage qui se fera autour de ces valeurs me semblera tout aussi bon.

4 Likes

Si on veut augmenter le contrôle local avec sigQty = 7 :

  • sigStock = 150
  • maxstep = 5
  • sigQty = 7
  • WoT moyenne = (50+1)*(50 / 7)^5 = 948 265
  • WoT max = (150+1)*(150 / 7)^5 = 682 millions ( = 720 x WoT moyenne)
  • Z[N] = 948 265 ^ (1/5) = 16

Semble très bien aussi (ordres de grandeurs correspondants à l’observable)

1 Like

Ce que je voulais soulever avec ma remarque, c’est la question de la stratégie adopter pour Y[N]. Doit-on :

  1. privilégier Y[N] = sigStock / sigQty afin de maximiser N (puisque la règle de distance ne s’applique alors qu’à ceux ayant émis le max de certifications possibles)
  2. ou alors peut-on avoir Y[N] < sigStock / sigQty, et donc dans ce cas on étudie pas vraiment le max max, mais plutôt le cas moyen

Ou alors est-ce que j’ai carrément loupé un truc dans le raisonnement ? Il me semble qu’il est possible de raisonner sur le cas moyen, donc 2).

Car il faut bien que je code cette fonction Y[N] ! Et donc soit je fais une fonction qui colle au max, ou alors une plutôt à 80% du max, 50%, 20% … bref faut choisir.

Nmoyen = (50+1)*(50 / sigQty)^stepmax
Z[N] = Nmoyen ^ (1/stepmax) arrondi à l’entier supérieur

Est une bonne estimation. Il faut considérer que ce sont bien les sentry qui donnent la taille, tous les membres étant pointés par eux ! (à 1 step près)

Ce n’est pas le max qu’il faut analyser car il est la limite supérieure, inatteignable en pratique, mais bien une estimation moyenne. Il n’y aura pas formulation “exacte” car on ne sait pas ce que vont faire véritablement les membres.

Avoir un max supérieur permet de savoir quel domaine on arpente, mais seule l’estimation de la moyenne permet de savoir à peu près où l’on est. Ensuite suivant les actions de l’ensemble il pourra se passer un peu n’importe quoi.

Nul besoin d’aller plus loin.

Oui d’accord mais Z[N] n’est pas une fonction mais une constante dans ce cas, ce qui signifierai avoir des sentries uniquement à partir d’une certaine maturité de toile.

Pourquoi pas une fonction (je ne suis pas capable de la donner) qui exprimerai Z[N] en fonction de N justement ?

1 Like

Tout à fait possible : Z[N] = N^(1/stepmax)

Avec N = 127 et stepmax = 4 : Z[N] = 127^(1/4) = arrondi(3,35) = 4

C’est d’ailleurs exactement pour ça pour j’ai donné cette relation, pour avoir une formulation souple.

OK donc je l’avais tracée celle-ci :

Mais je méditais un peu sur le fait que c’était une pure expression par N et stepmax, sans lien avec sigStock ni sigQty, j’étais (et suis toujours) dubitatif du fait qu’ils n’y apparaissent pas.

Edit : mais en fait c’est tout con : cette formule nous donne le cas moyen, où chaque membre émet le même nombre de certifications de façon à atteindre N. OK, nickel.

3 Likes

Non les calculs ne sont pas corrects, ils sont faits pour maxstep = 6.

Idem.

Sinon je valide toutes les formules écrites par Galuel depuis le début, elles me paraissent toutes correctes.

Du coup le paramétrage avec stepmax = 6 et sigQty = 5 me semble le plus désirable en termes de rapidité d’expansion comparé à sigQty = 7.

De même, prendre sigPeriod = 1 semaine => 2 ans et 10 mois ne me choque pas, on pourrait même étendre sigValidity à 3 ans ou plus de façon à ne pas passer sa vie à certifier, et rendre l’action de certification plus lourde.

Bref je pencherais effectivement vers la solution :

  • sigStock = 150
  • sigQty = 5
  • stepmax = 6
  • sigPeriod = 1 semaine
  • sigValidity = 3 ans (facile à mémoriser)
1 Like

La valeur de sigQty conditionne le contrôle local, 5 peut sembler faible tout de même…

Il faut aussi tenir compte du fait que, en pratique, le nombre de signatures requises pour remplir le critère de distance sera supérieur à sigQty passé une certaine taille de toile, car la distance implique également une qualité des signatures : elles doivent répondre au critère de distance, et se faire certifier par 5 connaissances proches ne sera pas nécessairement suffisant. On l’a déjà constaté plusieurs fois dans TestNet, 1 signature n’était pas toujours suffisant.

Nous allons devoir simuler tout cela quoi qu’il en soit, notamment pour comprendre des effets que l’on ne voit pas au premier coup d’oeil comme la dispersion dont a parlé inso.

Par ailleurs, j’essaierai de sortir un papier à propos de l’application de la règle de distance dans TestNet, sous la forme d’une analyse des données, car on n’a pas encore observé cette expérience à la loupe.

1 Like

Ce qui est embêtant en terme de test avec test-net c’est 1 signature… Ca ne permet pas de tester un minimum de complexité de graphe, mais uniquement les transactions.

Hé bien si justement, l’implication du nombre de signatures minimales par la distance est bien reflété grâce à cela, car 1 seule signature ne garantit rien quant aux chemins possibles.

En tout cas, le test a cette vertu là.

Il y a quand même un dernier point dont je ne suis pas certain : le paramètre xpercent est-il nécessaire ou non ?

Car autant on peut entendre l’argument “si un groupe d’utilisateur s’organise pour devenir bloquant en distance, il vaut mieux pouvoir l’éviter”, autant on peut aussi considérer que c’est une vraie protection que d’être un point bloquant dès lors qu’on a suffisamment de certifications émises. Cela offre un pouvoir de contrôle.

Un avis là-dessus, tous ?

Est-ce qu’un groupe qui s’organise pour devenir bloquant en distance peut empêcher qu’on les certifie ?
Si non, alors ils ne sont pas bloquant…

Autre point dans les paramètres : les valeurs de idtyWindow et msWindow. il s’agit resptivement du délai d’inscription (dans la BlockChain) d’un document d’identité (idty) et du délai pour un document de demande d’adhésion comme membre (ms).
Lors de la première inscription, à priori, les deux documents (idty et ms) sont écrit en même temps, si le dossier est complet, c’est à dire si le nombre de certification est suffisant. Sachant qu’une certification a aussi un délai avant écriture).

En travaillant sur les tests du Sou, j’ai réalisé que ces paramètres étaient très liés (au moins lors de la 1ere inscription).

Quel délai peut on fixer pour qu’un « dossier » soit complet ?

A priori, il faut nécessairement que:

  • idtyWindow >= msWindow, car l’identité doit etre émise avant l’adhésion.
  • msWindow >= sigWindow, car l’adhésion précéde la certification

Le plus simple est de fixer tout à la même valeur, car un utilisateur va faire les 2 doc en même temps, puis demander aussitot une certification :
idtyWindow = msWindow = sigWindow

Ce délai (global) doit néanmoins permettre de recueillir les certifications, à temps humain.

Combien de temps peut il falloir poru recueillir sigQty ?

La question est importante surtout au début de la WoT, là où sigPeriod est le plus handicapant (peu de membres, et limité par sigPeriod - la durée entre deux certifications).
Le nombre de membre de départ (N(0) - nb membre du block #0) est aussi important, pour que la communauté puisse s’acroitre suffisamment vite.

EDIT : dans le cas du Sou (5 certifications) j’avais en tête de partir sur 3 à 4 mois de validité. Mais je parviens pas à simuler correctement l’impact. Je suis vraiment pas à l’aise en math, c’est clair…
Enfin ce qui est sûr c’est que le paramètre actuel (1 semaine) est mauvais… Je n’avais pas compris que le dossier devais etre complet pour que l’ensemble des docs soient écrit.