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.
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%.
1 Like
77,7 % me paraît bien aussi.
Je n’ai pas de données particulières pour fixer ce chiffre, en as-tu ?
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é.
Voyez-vous une erreur dans ma conclusion précédente sur le délai d’écriture “du dossier” : idtyWindow = msWindow = sigWindow ?
Non, pas d’erreur, c’est possible de choisir cela pour simplifier les choses.
28% est bien aussi, 28 = 7 + 7 + 7 + 7
Vous me direz “mais quel intérêt 4x7 ?”, à quoi on peut répondre : “faut voir…”
1 Like
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.
A la suite de ces travaux, je réitère ce que je disais aux RML8 : il va vraiment falloir pondre un article détaillé résumant tout ça 
NB : Si nécessaire je peux tenter de m’en charger, ça me permettra de me replonger dedans. Vous m’avez un peu largué là
1 Like
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.
1 Like
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 :
Rappel des formules :
- WoT (stepMax,sigQty) = (sigStock+1)*(sigStock / sigQty)^(stepMax-1)
- WoT moyenne (stepMax,sigQty) = (50+1)*(50 / sigQty)^(stepMax-1)
- WoT moyenne (5,4) = (50+1)*(50/4)^4 = 1.245.117
- WoT moyenne (5,5) = (50+1)*(50/5)^4 = 510.000
- WoT moyenne (6,5) = (50+1)*(50/5)^5 = 5.100.000
- WoT moyenne (6,6) = (50+1)*(50/6)^5 = 2.049.575
- WoT moyenne (6,7) = (50+1)*(50/7)^5 = 948.265
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.
Je ne comprends pas que WoT moyenne (sigQty,stepmax) soit décroissante en stepmax…
Il faudrait rappeler la formule :
- WoT (sigQty,stepmax) = (sigStock+1)*(sigStock / sigQty)^(stepmax-1)
- WoT moyenne (sigQty,stepmax) = (50+1)*(50 / sigQty)^(stepmax-1)
Qui est donc décroissante en sigQty et croissante en stepmax.
Parce qu’en citant les paramètres dans cet ordre “pour sigQty et stepMax” et sans rappeler la formule, la suite est incompréhensible…