Récapitulatif sur les règles de la Toile de Confiance

Bonjour à tous,
J’essaie de faire le point sur le pourquoi et le comment de la Toile de Confiance et je n’arrive pas à trouver de document à jour (c’est peut être moi qui cherche mal).

J’ai noté les règles suivantes :

  • Règle des Nombre de pas maximum
  • Règle du nombre maximum de signature émise
  • Règle du nombre signature valide minimum

Y en a t’il d’autres ?

J’en profite pour partager la bafouille que j’ai écrite au sujet de la Toile de Confiance.


La Gestion des membres

De la nécessité d’un contrôle

UCoin est un logiciel permettant de créer une monnaie libre au sens décrit dans la TRM (Théorie Relative de la Monnaie).
Cette théorie implique que les unités monétaires sont co-produites par chacun des membres d’une même communauté.
Il est donc essentiel que les membres de la communauté soit bien identifiés et (re)connus.

Dans un monde parfait, un simple formulaire d’inscription pourrait suffir. Chaque membre aurait à remplir ce formulaire pour faire parti de la communauté et commencer à co-produire des unités monétaires.

Néanmoins, quand il s’agit de monnaie, des comportements inadaptés sont susceptibles d’aparaître.
En effet, il est tentant de s’inscrire avec plusieurs identités et ainsi de produire un surplus d’unités monétaires à son avantage.
Ceci est d’autant plus vrai qu’il s’agit d’identités numériques et qu’il est possible d’en créer autant que l’on en souhaite.

Il convient donc de s’assurer que les membres ne disposent que d’une seule identité numérique.

À qui doit on faire confiance ?

Comment s’assurer que les membres ne disposent que d’une seule identité numérique ?
Cette question mérite réflexion…

Prenons l’exemple du rescencement de la population française.
Ce sont les services de l’état qui « créent » les identités et les enregistent dans les différents fichers (aka. bases de données) de l’état. Les fonctionnaires agissent comme « tiers de confiance » au nom de l’état Français.
Les moyens de contrôles utilisés peuvent être des justificatifs administratifs (déclaration de la maternité, justificatifs de domicile, …). Ces moyens sont loin d’être infaillibles puisqu’il est trivial de créer des faux documents (et ainsi obtenir de vrais-faux papiers). Néanmoins, les mesures prévues par la loi pénale en cas de fraude sont trés disuasive.

Pour une monnaie construite uCoin, il est illusoire de vouloir obtenir quoique ce soit de l’état pour garantir l’unicité des identités numériques.

Faut il alors créer des institutions propres à uCoin ? Des tiers de confiance uCoin qui font ce travail ? Une justice uCoin ?
Si oui, sur quels critères décident on de qui est un « tiers de confiance » et de qui ne l’est pas ?
Et comment vérifie t’on que le travail de ce « tiers de confiance » fait bien son boulot ? Qu’il n’abuse pas du système à son propre avantage ?

Mettre tout le monde sur le même pied d’égalité

Pour uCoin, utiliser un tiers de confiance créé plus de problèmes qu’il n’en résout.
Plutôt que de confier beaucoup de pouvoir dans les mains de quelques uns, essayons de distribuer peu de pouvoir dans les mains de tous. En clair, tentons de créer un système de confiance autonome et auto-régulé par ses membres.

Ce genre de système existe déjà sans que nous y faisions vraiment attention. Prenons l’exemple de la file d’attente dans un magasin. Les clients arrivent les uns aprés les autres et personne n’est vraiment ravi d’avoir à attendre son tour.
Doit on embaucher un gestionnaire de la file d’attente (un tiers de confiance) qui s’assure que les cliens soient servis les uns aprés les autres en fonction de leur ordre d’arrivée ?
N’est il pas plus efficace d’expliquer à tout un chacun le comportement attendu dans une file d’attente ?
Si les règles sont justes et bien comprises (passage dans l’ordre d’arrivée), chacun s’y plie.

Ne nous soumet pas à la tentation

Évidement, cet exemple fonctionne car il est impossible de doubler tout le monde sans être repéré.
Chacun dans la file d’attente est en mesure de contrôler l’ordre de passage : qui est arrivé avant moi et qui est arrivé aprés moi ?
Pour qu’un système auto-régulé puisse fonctionner, il faut donc confier aux utilisateurs un pouvoir de contrôle sur les autres utilisateurs.

Ucoin est conçu en partant du principe que la grande majorité des utilisateurs, s’ils sont sous le regard des autres utilisateurs, adopteront le comportement attendu.

3 « J'aime »

Je crois qu’il n’y a que ces règles là, et même je ne considère que la 1ère et la 3ème règle que tu cites, à savoir la distance et le nombre minimal de signatures.

Le reste ce sont plutôt des limitations, comme :

  • la durée de vie d’une certification, d’une adhésion
  • le nombre maximal de certifications par membre
  • l’impossibilité de dédoubler la certification pour une même personne (certification permanente)
  • le délai d’attente entre 2 émissions de certifications

Je voulais faire un document en ce sens pour résumer nos toutes dernières évolutions du protocole, vu qu’il sera implémenté dans les prochaines monnaies, et que l’on a besoin d’éclaircir tout cela.

Je ne suis pas contre un peu d’aide. Si ça vous va, je vais plutôt compléter ce fil du forum avec chacune des règle et limitation, de façon à ce que ceux qui le désirent puissent faire un document récapitulatif avec commentaires et explications, par ailleurs.

Au pire, je ferai simplement un document agrégat par la suite.

2 « J'aime »

Ce post pourrais être mis sur le blog d’ailleurs !

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 « J'aime »

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 :slight_smile:

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_period secondes 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 de sig_period aprè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 :slight_smile:

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 : REJOINDRE dans 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_period temps
    • la compte total de certificats inscrits et en cours de validité est inférieur à sig_stock

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 « J'aime »

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 « J'aime »

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 « J'aime »

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 :slight_smile:

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 ! :slight_smile:

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 ?