Moi ça me va. Je suis prêt à aider dans ce sens.
En français par contre… En tout cas dans un premier temps.
Oui je le ferai en français sur ce fil, puis cela pourra être traduit par la suite.
1 Like
La suite de ma bafouille…
Un système de cooptation distribué
Un utilisateur souhaitant devenir membre d’une communauté existante, quelque soit sa taille, commence par « déclarer » son identité sur le réseau.
Par cette action, il s’engage sur l’honneur et déclare que :
- Il peut être identifié de manière unique par les membres de la communauté via cette identité numérique (autrement dit, il s’engage à ne pas créer d’identités multiples au sein du système).
- Il comprend que les unités monétaires sont co-produites par les membres de la communauté monétaire (autrement dit, qu’un dividende universel est périodiquement versé à chaque membre)
Évidemment, cela ne suffit pas pour que cet individu devienne membre de la communauté.
Le concours des membres déjà en place est nécessaire.
En effet, ces derniers ont le pouvoir de coopté les utilisateurs souhaitant rejoindre la communauté.
Un membre peut, au travers d’une signature numérique, signaler au reste de la communauté que :
- Selon lui, cette identité numérique correspond bien à un être humain vivant et que cet être humain n’est pas déjà identifié dans le système par une autre identité numérique.
- Selon lui, cette personne comprend que les unités monétaires sont co-produites par les membres de la communauté monétaire (autrement dit, qu’un dividende universel est périodiquement versé à chaque membre).
Si l’utilisateur obtient suffisamment de confiance, (autrement dit suffisamment de signatures), le système intègre cet utilisateur « membre de la communauté ».
Est ce que ces deux schémas récapitulatifs vous semblent utiles pour comprendre le fonctionnement de la Wot ?
Nouveau certificat
Expiration d’un certificat
Attention, les question posées aux tests sig_period et sig_stock s’opposent, l’une doit être vrai (sig_period) et l’autre fausse pour passer… Il faut harmoniser les questions pour avoir deux vrais.
Bien cette idée de schémas 
Quelques précisions, même si tu les as peut-être déjà en tête :
Nouveau certificat
- Sig_period: ce n’est pas tellement que l’émetteur doit attendre que le fait qu’il se soit passé
sig_periodsecondes depuis la dernière écriture.
Dans les faits donc, un membre peut certifier 3 personnes d’un coup, mais chacune d’entre elles ne pourra être inscrite au plutôt qu’avec un délai desig_periodaprès la précédente.
Et par ailleurs, il existe aussi désormais le paramètre sigWindow qui dit qu’un certificat émis mais non-inscrit pendant une période supérieure à sigWindow est périmé et ne pourra jamais être inscrit.
Donc si sigWindow = 1 semaine et sigPeriod = 3 jours, un individu pourra émettre autant de certificats qu’il souhaite (grosso modo) mais ne pourra en écrire au mieux que 3 dans la semaine (un le lundi à 08h00, jeudi.à 10h00, dimanche 22h00 par ex.).
-
Sig_stock: même remarque que @vit. Je tournerais la phrase en “L’émetteur a-t-il encore des certifications en réserve ?”
-
Sentries:
membres ayant émis au moins un certificat
Alors non, c’est un nombre qui dépend de N:
N Y(N)
10 2
100 4
1000 6
10000 8
100000 12
1000000 20
La fonction correspond à la courbe jaune du 2ème graphique de ce post.
Ça complique l’explication, je l’admet
Expiration d’un certificat
Pour l’expiration, c’est bien cela. Mais elle ne déclenche que la règle de Sig_quantity, et donc elle n’exclue le membre que s’il n’a plus assez de certifications, sans regarder la distance.
La règle Sentries s’applique exclusivement lors d’un renouvellement du membre (donc au moment où il rejoint la toile au tout début, puis de façon régulière pour éviter l’expiration de son adhésion).
Ok merci pour ces précisions.
Ça complique les chose en effet… Je vais faire évoluer les schémas en ce sens.
Comme promis sur le salon de discussion, voici un petit récapitulatif concernant le processus permettant d’être membre d’une monnaie libre avec Duniter.
Je ferai cela en 3 scénarios.
Scénario 1) Nouveau venu
Dans ce 1er cas, considérons un individu qui découvre une monnaie libre reposant sur Duniter et dont il voudrait faire partie, afin de produire lui aussi sa part de monnaie.
Les pré-requis
Cet individu (appelons le “I1”) va devoir produire un ensemble de documents, de 3 types au total, qu’il sera nécessaire de présenter ensembles afin de pouvoir devenir officiellement membre.
Ces documents peuvent être créé facilement et librement avec un logiciel client de Duniter comme le logiciel Sakia. Notamment, le logiciel créera automatiquement un trousseau de clés cryptograhpiques personnel permettant de signer tous les documents émis.
Documents pouvant être émis par l’individu lui-même
- Identité : document représentant sa personne, son identité. Ce document comprend :
- un identifiant : par exemple un pseudonyme ou son nom et prénom réels
- une clé publique : la clé publique du trousseau généré par le logiciel client
- un tampon temporel : c’est un identifiant particulier qui sert de date de réalisation du document.
- une signature cryptographique
Le tampon temporel n’est jamais connu à l’avance, il est donné par le réseau de façon continue à chaque instant qui passe. Ainsi il n’est pas possible de réaliser des documents avec une date future mais uniquement avec une date passée ou présente.
- Adhésion : document attestant de la volonté de l’identité de faire partie des membres de la monnaie. Ainsi, une identité qui fuite sur le réseau ne suffit pas à ce que celle-ci soit considérée comme membre potentiel. Ce document contient :
- un résumé de l’identité, pour correspondance entre les 2 documents
- le type d’adhésion :
REJOINDREdans notre cas - un tampon temporel
- une signature cryptographique
Documents nécessitant l’intervention de membres existants
- Certificats : ces documents sont une attestation, par des membres existants, de la correspondance biunivoque entre identité et une personne réelle. Ceux-ci contiennent donc :
- un résumé de l’identité, pour correspondance entre les 2 documents
- une clé publique : celle de l’émetteur du certificat
- un tampon temporel
- une signature cryptographique
Le mode opératoire
Le nouveau venu commence donc par créer son identité avec un logiciel client, y adjoint sa demande d’adhésion, et publie le tout sur le réseau. A ce moment, les données sont en attente. En effet, il est nécessaire d’envoyer ces 2 documents avec les certificats permettant de devenir membre pour que l’ensemble des données du membre soient traitées par le réseau.
Admettons que I1 réalise ceci début janvier. Il a alors un délai pour récolter les signatures nécessaires de membres actuels afin de les ajouter à son “dossier” de membre en devenir. Ce délai est par exemple de 1 mois (cela dépend des monnaies, c’est un paramètre). Le membre a donc un mois pour prouver la validité de son identité.
Tout individu doit respecter 2 règles afin d’être et de rester membre :
- Avoir suffisamment de signatures. Le nombre exact est inscrit dans les paramètres de la monnaie, sorte de constitution immuable de la monnaie.
- Être suffisamment proche de tous les autres membres. La proximité se définit par le jeu des certificats constituant des chemins jusqu’à l’individu, en l’occurrence I1. Il doit exister un tel chemin jusqu’à I1 par ces chemins, en respectant une distance maximum là aussi définie par les paramètres de la monnaie.
Traduction technique
En termes techniques, la publication de ces documents n’entraîne pas d’inscription dans la blockchain. Tout document est en zone d’attente tant qu’il est valide (car les documents d’identité ont une date de péremption !) mais nécessite la jonction d’autres documents pour être publié.
Concrètement, l’ensemble des documents Identité, Adhésion, Certificats est inscrit à la blockchain dès qu’ils respectent l’ensemble des règles et contraintes de la toile de confiance.
Les 2 règles ont été énoncées plus haut, voici maintenant les contraintes :
- tout document périmé ne peut être inscrit dans la blockchain
- tout certificat ne peut être inscrit que si :
- le dernier certificat de la clé émettrice a été inscrit il y a plus de
sig_periodtemps - la compte total de certificats inscrits et en cours de validité est inférieur à
sig_stock
- le dernier certificat de la clé émettrice a été inscrit il y a plus de
SI toutes ces règles et contraintes sont respectées, alors l’ensemble des documents sont inscrits dans un block. Appelons ce block #100. I1 est alors membre depuis ce bloc.
Il peut désormais lui aussi émettre des certificats pour les autres membres, ainsi que de produire sa part de monnaie de façon conforme aux monnaies libres.
3 Likes
Scénario 2) Rester membre
Continuons avec notre individu I1. Il est désormais membre et entend bien le rester.
Toutefois rester membre ne se fait pas sans efforts, et notamment cela impose 2 conditions :
- Il doit à tout moment respecter la règle du nombre minimal de signatures
- Il doit réitérer, régulièrement, sa volonté de rester membre
Les pré-requis
Ils sont au nombre de 3 :
- L’individu doit être membre
- Il doit réitérer sa volonté d’être membre, régulièrement
- Il doit perpétuellement recevoir de nouvelles certifications
En effet, l’adhésion envoyée initialement a aussi une date de validité en plus de sa date de péremption. Une fois la date de validité passée, et faute de renouvellement, le membre est alors automatiquement exclu.
De même pour le manque de certifications. L’exclusion est automatique dès qu’une certification expire et que le compte n’y est plus.
Documents pouvant être émis par l’individu lui-même
- Adhésion : l’individu n’a qu’à utiliser son logiciel client favori pour réitérer sa volonté d’être membre. Le document est identique à celui du scénario 1), mis à part la date et la signature.
Le document est immédiatement inscriptible, à condition toutefois que le membre continue de respecter la règle de distance décrite dans le scénario 1) (être suffisamment proche de tous les membres).
Bien évidemment, les membres présents quand I1 est devenu membre ne sont probablement plus les mêmes désormais. La règle de distance requerra certainement des certificats nouveaux, provenant d’autres membres, et potentiellement en plus grand nombre (jusqu’à même dépasser la règle du nombre certificats minimum !).
Documents nécessitant l’intervention de membres existants
- Certificats : De nouvelles attestations d’identité sont nécessaires afin d’une part de combler celles, précédentes, qui expirent, mais aussi afin de se créer des chemins permettant de respecter la règle de distance qui sera nécessaire pour renouveler l’adhésion.
Le mode opératoire
Le membre peut produire et publier son renouvellement d’adhésion à volonté. Et contrairement au scénario 1), les certificats peuvent être ajoutés au fil de l’eau.
Traduction technique
Pour l’adhésion, le réseau traitera le document et l’inscrira dans la blockchain dès lors que le membre respecte les règles de nombre de signatures et de distance
Pour les certificats, dès que l’un d’entre eux est produit et publié, il peut être directement inscrit dans la blockchain (si toutefois les contraintes sig_period et sig_stock sont respectées).
3 Likes
Scénario 3) Redevenir membre après exclusion
I1 peut malgré tout perdre son statut de membre, pour 5 raisons possibles :
- il a quitté la communauté monétaire
- il a révoqué son identité, qui est devenu invalide
- une ou plusieurs certifications ont expiré, et la règle du nombre de signatures n’était plus respectée
- il n’a pas renouvelé son adhésion
- soit par choix
- soit par non-respect de la règle de distance
Dans un tel cas, sauf révocation de l’identité, I1 peut redevenir membre s’il le souhaite.
Les pré-requis
Identiques au scénario 1). Mis à part que l’identité n’a pas besoin d’être publiée de nouveau, celle-ci étant déjà inscrite dans la blockchain.
Cependant, le membre bénéficie également des certificats encore valides inscrits dans la blockchain. Ainsi, il n’est pas obligé de repartir de zéro ! Ces certificats seront considérés comme faisant partie du dossier permettant de devenir membre.
A noter que quand un individu “quitte” la communauté monétaire, ces liens ne sont pas détruits pour autant : ils continuent leur action tant que leur date de validité n’est pas expirée. Par ailleurs, un lien ne peut pas être révoqué ni détruit : il faut donc faire attention lors de l’émission d’un certificat !
Le mode opératoire
Identique au scénario 1).
Traduction technique
Identique au scénario 1).
3 Likes
Etant donné que la Toile de Confiance est un graph orienté, je souhaiterais savoir si l’orientation du lien est pris en compte dans le calcul du nombre de pas entre deux identités.
Autrement dit, en partant du principe que A, B et C sont membres (1 seule certification nécessaire), C est il a un ou deux pas de A ?
Merci 
Le graphe est orienté. C est a deux pas de A.
Merci.
Autre question au sujet des certification.
Admettons que A a un stock de certification (sigStock) à 10.
A certifie B à l’instant t. Cette certification expire à t + 10.
Le stock de signature de A passe donc de 10 à 9.
Le nombre de certifications (sigQty) de B passe à 1.
Il certifie une nouvelle fois B à t + 2.
Est ce que le stock de signature de A passe à 8 ?
Est ce que le nombre de certifications (sigQty) de B passe à 2 ?
En fait, le protocole dit qu’il ne peut pas (voir le point “Replayability” et son implémentation dans le code).
Donc les questions:
ne se posent pas.
Un beau RTFM ! 
Je dirais plutôt qu’il s’agit d’un prétexte parfait pour faire le lien avec le protocole et le code !
Pourrais tu expliquer ce paramètre ?
idtyWindow
Si je comprends bien, c’est utile dans le scénario 1.
Pour devenir membre un individu doit :
- publier sa déclaration d’identité
- collecter un nombre de certifications suffisantes
- respecter la règles des pas
Et cela doit être fait dans le laps de temps indiqué par idtyWindow (et avant que l’identité expire bien sûr) ?
J’ai bon ?
Tout bon.
Ce paramètre est là pour “oublier” les identités périmées, histoire qu’on ne déterre pas une identité après 6 mois d’inexistence par exemple.
C’est ça, à ceci près que le timestamp est appliqué par le membre et avant la signature : il fait partie des données signées.
Quand je disais qu’il était donné par le réseau, c’est parce qu’il s’agit du hash d’un bloc : or le hash n’est pas connu par avance puisqu’il est déterminé par la preuve de travail. C’est en ce sens qu’il est donné par le réseau = l’ensemble des acteurs participant à réaliser des preuves de travail.
Par exemple le timestamp du block#3000 est :
3000-00049CDD40A0FF6BB4936F37B15C8B8373580DCE5632AB80B38A8765AFBEB5E4
Et donc, au moment où il produit un document, un utilisateur regarde le dernier bloc connu de la blockchain, en extrait l’identifiant de bloc comme preuve, marque temporelle.