Ce que je voulais soulever avec ma remarque, c’est la question de la stratégie adopter pour Y[N]. Doit-on :
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)
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.
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.
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 ?
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.
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 :
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.
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.
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.
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.
Attention, sigperiod est aussi handicapant arrivé à une certaine taille de la wot ou il faut renouveler les certifications pour ne pas qu’elle s’effondre ainsi que certifier de nouvelles personnes pour qu’elle continue de grandir
Le problème n’est pas qu’on puisse ou non les certifier, mais c’est le fait qu’il puisse exister des chemins suffisants en qualité partant d’eux jusqu’au nouveaux entrants. Je me pose la question de ceux qui émettraient assez de certifications pour devenir points de contrôle, mais dont les certifications resteraient volontairement limitées en portée. Par exemple, des membres qui feraient exprès de certifier uniquement des membres qui eux ne certifient personne, et donc pour lesquels il ne peut exister aucun chemin.
Du coup, j’ai ma réponse : en effet il existe des cas de nuisance possible par ce biais. xpercent est bel et bien nécessaire. Reste à fixer sa valeur … au doigt mouillé on évoquait un chiffre de 90% ici. On peut aussi invoquer la loi de Pareto ici pour mettre un 80%.
La seule donnée empirique que je connaisse à ce sujet est ce qu’on appelle la minorité de blocage en droit des entreprises, que j’ai déjà vu fixé à 34% (> 1/3), mais ça peut être n’importe quoi.
Ca doit rester possible, c’est correct, mais doit être assez gros pour ne pas être nuisible non plus en effet. Une minorité de 22,3 % ou de 34% semble correcte, 10% semble trop faible et 50% revient à donner tout pouvoir à la majorité.
