On pourrait aussi grouper les requêtes et avoir leurs preuves ayant une partie en commun. Ca peut faire de grosses optis 
1 Like
Alors oui pour le côté “il me suffit du bloc pour appliquer le revert”. Dire explicitement “il y a eu expiration de la certification, de l’adhésion, ou il y a eu révocation implicite” OK. C’est très bien pour le revert et ça facilite la synchro car tout est explicite.
Par contre en mode nominal il faut de toute façon pouvoir justifier cette action et donc s’en souvenir dans la base de données avant écriture de cette information dans un bloc, et pour les nœuds recevant le bloc d’accepter cette information.
Tout de suite les grands mots ! Bon allez, ça me fait sourire 
Facile : 2 mois après le fork. En effet comme les identités, certifications et adhésions ont une durée de vie hors blockchain de 2 mois, fatalement le blockstamp devra être pris sur un bloc v11 au bout de 2 mois. Sans quoi le document serait immédiatement périmé.
4 Likes
Ce n’étais une pique, le protocole que tu a conçu est étonnamment bien fait et efficace, il aurait pu comporté bien plus d’erreurs que ça, et j’aurais sans doute fait bien pire. Je me rend juste compte a l’usage qu’il a des des erreurs conceptuelles, ce qui est tout a fait normal 
Je trouve juste le qualificatif un peu fort concernant ce point, car pour moi une erreur conceptuelle mène à une incohérence.
Une erreur de conception aurait probablement était plus correct 
2 Likes
Et encore je ne trouve pas que ce soit une “erreur”, car ce serait affirmer qu’il existe l’erreur et la non-erreur de façon absolue, de la même façon qu’il existerai la valeur et la non-valeur de façon absolue.
A la place on pourrait dire qu’il existe des choix préférables de conception, pour telle ou telle raison.
Je ne dis pas ça pour me justifier, je suis d’accord sur le fait qu’il aurait été préférable d’inscrire les données implicites de façon explicite. Simplement je rejette les absolutismes (ou raccourcis qui font croire qu’il existe un absolu). Cela devient une réaction épidermique, c’est certainement la relativité qui rentre
6 Likes
Il ne faut pas tomber non plus dans la relativité absolue, qui n’existe pas plus.
Il existe bien des erreurs selon le référentiel qui a été établi pour juger du juste et du faux.
Voilà, sauf que ledit référentiel n’est pas clairement établi et a même tendance à changer.
1 Like
ok
1 Like
Si le référentiel change c’est donc qu’il s’inscrit dans un référentiel plus vaste qui juge de ce qui change et de ce qui ne change pas.
TODO : Maybe add
username_is_outdistanced. It needs to be done once every block so it’s
maybe not too much computationaly heavy for 5 minutes blocks.
J’ai une proposition sur ce point : Le noeud duniter pourrait évaluer la règle de distance chaque fois qu’il écris un piscine une certification (la piscine c’est une bdd sur disque dur donc on écris dedans) il calculerai la règle de distance du membre receveur si et seulement si c’est la 5ème certif ou + et que le receveur n’est pas encore membre.
On mise ainsi sur le fait que la règle de distance varie très peu voir pas du tout tant que le dossier de certif reçu ne change pas. Il faudrait alors rajouter un nouveau champ dans les piscines des identités indiquant si elle est outdistanced ou pas, en précisant bien coté client que ctte donne est une estimation a titre indicatif et que dans l’absolu une identité affichée distance OK peut ce retrouver outdistanced d’ici que son dossier son dispo mais ces cas seront très rares.
De toute façon on ne peut pas maintenit le fonctionnement actuel qui est de calculer la distance a chaque appel client, ce que je propose est donc un compromis pour calculer la distance 1 seul fois par nouveau membre (deux fois s’il reçoit une 6 eme certif avant d’entrer dans la wot).
A chaque fois qu’il y a création ou expiration d’une certification, on propage la modification de distance dans la toile de saut en saut tant que celle-ci varie. On ne calcule alors que partiellement la toile uniquement dans ce cas là.
@nanocryk attention moi je parle du cas des identités et certifs en piscine, rien en blockchain, donc ce que tu dit ne s’applique pas au cas dont je parlais.
Quand a ce que tu propose, je pense que c’est trop que tout les nœuds fassent ça, la wot est un système chaotique, une certif de plus ou de moins et il faut tout recalculer. Et le temps de calculer quelle partie est nécessaire et suffisante a recalculer serait encore plus gourmand que de tout recalculer !
je pense que l’info qui consiste a savoir si un membre déjà membre est outdistanced ou pas pour se renouveler, il faut mieux que cette info ne soit donnée que par quelques nœuds spécialisés dans des services de statistiques avancés (style g1-monit), les clients pouvant même requeter ces nœuds spécialisés juste pour ça (y a une API a faire, style Duniter Advanced Statistics Api, ou autre nom, ce sera probablement l’un de mes futurs projets).
Ah d’acc.
Mais si les calculs sont faits avec les données en piscines, on peut avoir par la même occasion des données valides quand elles entrent en bloc, non ?
Non il faut nécessairement refaire le calcul de distance au moment de l’écriture du bloc car il est possible que dans certains cas une très légère variation fasse basculer outdistanced de false a true.
Et ce calcul est trop complèxe pour être fait une fois à la fin de chaque bloc contenant un changement de certification ?
Oui, pour l’instant ça va encore mais avec N qui grandi le temps de calcul va croitre selon exp(N), il est impensable que chaque noeud duniter fasse ce calcul pour l’intégralité des membres a chaque bloc contenant un évènement wot !
EDIT : Attention il faut bien différencier deux types de calcul différents :
- le calcul qui consiste a évaluer si un membre ciblé respecte la règle de distance (qui lui est déjà couteux mais doit nécessairement être fait par tout les nœuds a chaque entrée/renouvellement du membre concerné)
- Le calcul qui consiste a évaluer cette règle de distance pour tout les membres, qui lui est exponentiellement plus couteux encore (déjà plus de 30 secondes pour la wot actuelle avec une machine puissante !!). C’est ce second type de calcul, que je fais déjà dans g1-monit, que je souhaite réserver aux nœuds spécialisés de statistique.
3 Likes
En effet je comprends mieux. Va pour pour des nœuds spécialisés.
Sinon j’ai renommé CheckSig et CheckMultiSig en CheckDocSig et CheckDocMultiSig, et j’ai rajouté 2 nouveaux opcodes CheckMsgSig et CheckMsgMultiSig. Ces 2 derniers pourraient permettre la conceptions de contrats intelligents plus avancés à base d’oracles/tiers : on défini un contrat basé sur le résultat d’un événement : “Quelle équipe va gagner un match ?”, “Est-ce le vol va être annulé ?”. Les différentes réponses sont connues à l’avance et stockées dans le script, et seule la bonne réponse sera signée par l’oracle/tiers ce qui permettra de d’exécuter la partie correspondante du contrat.
Je vais rajouter un opérateur pour découper une valeur (split à telle position), on pourrait alors avoir dans le message une information unique (pour éviter la réutilisation hors contexte, le timestamp et un nonce par exemple) et des valeurs numériques, par exemple pour exprimer “Si telle valeur est supérieure à X”.
J’essaie de calculer plus précisément la complexité de ce calcul. Il y a plusieurs algorithmes possibles, j’étudie celui que j’utilise.
-
Définitions :
Nombre de membres : N
Nombre de référents : S <= N -
Calcul et tri des référents [o(N log^2(N))], à faire une seule fois :
- Pour chaque membre [N]
- chercher le nombre de certifications provenant ou aboutissant à ce membre [log^2(N)]
- tester si le membre est référent [1]
- Tri des référents [S log(S) <= N log(N)]
- Pour chaque membre [N]
-
Calcul du nombre de référents atteints par un membre ou nouveau venu m [o(N^2 log^2(N))] :
- set ← {m} [1]
- Faire 5 fois [1] :
- Pour chaque élément e de set [N]
- Pour chaque membre f ayant certifié e [N log(N)]
- ajouter f à set [log(N)]
- Pour chaque membre f ayant certifié e [N log(N)]
- Pour chaque élément e de set [N]
- Si m est un nouveau venu, le retirer de set [1]
- nombre de référents atteints n ← 0 [1]
- Pour chaque élément e de set [N] :
- si e est un référent, n ← n + 1 [log(N)]
-
Calcul du nombre de référents atteints pour tous les membres [o(N^3 log^2(N))] :
- Pour chaque membre [N] :
- Calcul pour ce membre [N^2 log^2(N)]
- Pour chaque membre [N] :
La complexité du calcul est donc majorée par o(N^2 log^2(N)) pour un membre ou nouveau venu et par o(N^3 log^2(N)) pour l’ensemble des membres (la complexité du calcul des référents est négligeable dans les deux cas).
Ce sont des valeurs qui grossissent rapidement avec N, mais qui ne sont pas exponentielles, simplement algébriques.
3 Likes
merci @gerard94, oui j’ai dit que ça évoluai exponentiellement sans avoir vérifier vraiment, ce que je voulais dire, c’est que c’est a mon avis trop couteux pour être fait par tout les nœuds !
2 Likes