BrightID - Identité unique décentralisée

Je parlais un peu avec castall de BrightID, ils prévoient une beta pour novembre.
Ils travail sur l’intégration etherum, il m’a demandé si il pouvait préparer une intégration avec la blockchain Duniter, je lui ai dit que oui ça serait chouette, mais que je ne pouvais pas parler à la place des dev.

Si jamais vous voulez vous ouvrir à cette idée, il est joignable via ce canal: https://hub.decstack.com/projects/channels/brightid

2 Likes

Je ne vois pas ce que signifierais une intégration de BrightID si ce n’est remplacer la WoT actuelle, ce qui ne me semble pas à l’ordre du jour.

Pour autant, BrightID me semble extrêmement prometteur comme alternative à la WoT Ǧ1 pour développer une autre monnaie libre n’ayant pas les limitation d’extension de la Ǧ1 (mais n’ayant pas certaines qualité de la Ǧ1 comme ça résistance à effondrement en cascade).

Il me semblerait donc pertinent développer/adapter Duniter, Juniter, DURS/Runiter, ou autre logiciel implémentant le DUP (Dividend Universel Protocol si je ne me trompe) de manière à pouvoir accueillir un code monétaire données (celui qui en fait une monnaie libre) et une WoT données (celui qui rend au DU de cette monnaie libre son caractère Universel).

Ou, si cela n’est pas faisable (ou demande un travail que personne ici ne souhaite prioriser) il me semblerais alors pertinent qu’une développement de code monétaire type Monnaie Libre soit construit par dessus la WoT BrightID plutôt que l’inverse.

1 Like

En fait pour savoir ce qu’il faudrait faire ici, il faudrait que quelqu’un fasse la démarche de se renseigner sur BrightID et se documente. Sous quelle forme est-ce que ça s’interfacerait avec Duniter ? etc…

3 Likes

Si nous pouvions trouver le moyen de nous assurer paisiblement d’identités uniques, sans avoir l’impression de prendre le risque de transgresser un texte biblique susceptible d’entraîner l’humanité dans l’obscurité pour des siècles et des siècles. Alors nul doute que la monnaie libre pourrait enfin nous autoriser à nous faire confiance en nous même pour commencer.

Nous pourrions alors enfin nous préoccuper efficacement, d’un coté de mobiliser des codeurs, de l’autre des usagers ordinaires au lieu d’expliquer à longueur de posts et d’apéros, l’anathème de la transgression de la divine licence.

5 Likes

Cela nécessiterai de modifier le protocole Blockchain de manière a ce qu’il devienne agnostique du système d’identification utilisé, mais cela impliquerai que la blockchain DUP ne contiendrai plus les “preuves” qui attestent que les règles du système d’identification sont respectés (a moins de devenir une blockchain ultra générique type FYgg).

Il y a une autre solution plus simple et a laquelle je serait favorable : Avoir 2 types de nœuds : un qui gère la monnaie et un qui gère le système d’identification. On aurait alors deux réseaux superposés ayant chacun leur propre blockchain (dans le cas ou système d’identification repose sur une blockchain, ça peut être autre chose).

En tout les cas, rendre DUP agnostique du système d’identification est un chantier colossal et nous avons déjà beaucoup d’autre priorité pour les années a venir.
Il me semble donc en effet infiniment plus facile que l’équipe de BrihtID implémente leur propre protocole de monnaie libre par dessus leur système (avec l’aide de notre expérience pourquoi pas).

1 Like

Je viens de discuter avec castall de BrightID, il est très intéressé techniquement par Duniter, et l’éthique du projet lui plaît. Il a toutefois quelques questionnements sur les aspects économiques, il en a déjà discuté avec @Inso sur reddit : https://www.reddit.com/r/CryptoUBI/comments/6udflu/how_do_crypto_ubis_arrive_at_their_chosen/

De mon coté je lui ai fait part de nos besoins techniquement parlant, et il pense que BrightID sera tout a fait en mesure d’y répondre.
En particulier il nous sera possible de définir des seuils différents pour le droit a co-créer sont DU et le droit a écrire dans la blockchain en demandant un “trust score” plus élevé pour le droit a écrire des blocs.

Il faut bien comprendre que BrightID est soumis au mêmes problèmes que notre toile de confiance, des mots mêmes de castall :

elois :
The difficulty seems to me to be to succeed in choosing a good threshold for the “trust score”.
castall :
yes, that will take some experimentation
It’s a trade off. Too high and it’s hard to get new users, too low and you have more sybils
But when the network becomes worldwide, the getting new users part won’t be an issue
It’s while the network is growing that the tradeoff needs to be made

L’avantage serait que la toile serait bien plus grande que notre communauté Ğ1 car le réseau BrightID a vocation à être utilisé par de nombreuses communautés pour tout types de besoins.

Concernant les considérations techniques, les nœuds BrightID fourniront une API Rest qui répond du JSON donc se sera assez simple à utiliser (Le développement de leur API viens tout juste de commencer mais ils devraient avoir une 1ère version beta pour Novembre).

L’idée serait que chaque document identité comporte un identifiant BrightID.
Et chaque fois qu’un membre émet un document membership, le noeud qui essayera d’écrire ce document membership dans son bloc vas contacter l’API BrightID pour obtenir une preuve de “trust score” de l’identifiant BrightID associé a l’identité correspondante, si le trust score est toujours au dessus du seuil que nous aurons défini le membre est renouvelé, sinon le membre expire.

Dans cette idée, les documents identity et membership seraient conservés, seul le document certification disparaîtrait.

7 Likes

Merci @elois pour avoir fait cette démarche de recherche.

Alors, ça signifie que l’API BrightID doit permettre de répondre à la question “Quel est le trust-score de l’identifiant BrightID X à la date T ?”. Puisque quand on va vérifier un bloc, on vérifiera le trustscore à la date du bloc :slight_smile:

Mais sinon, techniquement ça a l’air intéressant à plusieurs niveaux :

  • Réduit la nécessité de faire des calculs de WoT complexes dans les noeuds Duniter, qui se limitent alors à gérer la monnaie
  • Simplifie les possibilités d’extensions de la toile
  • Permet de très facilement avoir une monnaie qui dépasserai les frontières de la francophonie

Les inconvénients sont qu’un des aspects critiques de Duniter reposerait alors sur un système annexe. Ceci dit, il est possible de prévoir des modes de secours, du type

en cas de défaut du système annexe, les noeuds Duniter gardent la dernière liste valide des membres pour faire fonctionner la monnaie en attendant un retour à la normale.

Ce qui implique de garder en cache une “liste des identités Duniter dont le trustscore a été suffisamment élevé pour le membership”.

En terme d’implémentation :

  • les noeuds Duniter devraient se partager une liste de noeuds BrightID à requêter (et il faudrait un moyen de les découvrir)
  • ces noeuds BrightID devraient eux même avoir un identifiant BrightID avec un trust-score associé pour éviter les attaques sybilles
  • les noeuds Duniter pourraient alors les requêter sereinement, avec une requête du type “je demande à 5 noeuds, si une réponse n’obtient pas une majorité de 4 noeuds, je considère qu’il faut redemander à d’autres noeuds. Au bout de 3 requêtes sans majorité, je considère le réseau BrightID dans un état KO, et j’utilise la liste des identités que j’ai en cache”.
4 Likes

J’ai lu et le sujet est comme souvent très mal approché dû au manque de mathématiques dans l’explication et la compréhension pourtant simplissime.

La croissance est la part de monnaie créée sur la monnaie existante. Mais en relativité cela s’entend part de monnaie individuelle créée sur masse monétaire moyenne : DU(t+1) / (M/M)(t).

Or DU(t+1) = DU(t) + c² M/N(t), et donc il s’ensuit :

DU(t+1) / (M/M)(t) = DU(t) / (M/M)(t) + c²

Et donc lorsque N augmente fortement M/N diminue, et ainsi la croissance de la monnaie est très forte, ce qui correspond très exactement à la demande de l’interlocuteur.

Exercice : quelle est la croissance actuelle de la Ğ1 ? Quelle était sa croissance il y a 6 mois ? Quelle sera celle dans 6 mois dans des conditions similaires ?

Le grand avantage des mathématiques, vraiment, c’est de pouvoir écrire en 20 caractères ce qui demande des romans entiers et des approximations loufoques aux non-mathématiciens.

1 Like

En effet, et cela peut être réalisé “simplement” avec un oracle qui gérerait la liste des membres. Ainsi on pourrait utiliser la WOT en insérant les résultats, mais plus tard passer à un autre système sans changer le protocole de la blockchain :wink:

J’ai deux choses à dire sur l’utilisation de systèmes externes :

  1. C’est possible, néanmoins il ne doit pas y avoir d’ambiguïté pour le système “hôte”, ici Duniter. À ce jour je ne sais pas comment on peut faire pour que la donné de BrightID intègre la blockchain Duniter tout en étant “certain” de l’authenticité des données qui seraient éventuellement inscrites/utilisées par Duniter.
  2. BrightID ne se construit pas de la même manière qu’une identité de la Ğ1, les enjeux ne sont pas les mêmes, les intentions pour créer une identité non plus. Je ne sais pas si c’est judicieux de se reposer sur leur protocole pour construire la Ğ1, et de manière générale je ne sais pas s’il est judicieux de se reposer sur un système externe.
3 Likes

C’est bien le but d’un oracle : insérer une vérité en ayant la plus grande certitude qu’elle le soit. Un système de caution permet de motiver la participation et la coopération tout en réprimandant les initiatives personnelles. Ici Duniter reste hôte et la gestion des membres est gérée off-chain et considérée comme une boite noire, permettant une modification sans fork (tant que les participants utilisent le même protocole off-chain, mais permettant une transition moins lourde).

Tout à fait d’accord pour BrightID.

Pour le calcul externe en revanche (en supposant que l’oracle fonctionne bien) est utile car il permet de décharger les noeuds les moins puissants ou non interessés. Tant qu’un grand nombre de personnes vérifient les calculs, alors le système est sûr et les autres peuvent se permettre de ne pas vérifier eux même.

Oui bien entendu :slight_smile:

C’est effectivement une question a creuser avec les dev de BrightID mais ils semblent très motivés pour pouvoir être utilisé par Duniter donc il est mais possible qu’il effectue les modifications nécessaires pour répondre a nos exigences (peut être même sont t"il déjà en mesure d’y répondre sans rien modifier); le seul moyen de le savoir c’est de continuer a en discuter avec eux :slight_smile:

Les enjeux me semblent quand même très similaires. Quel différence voit tu a niveau des enjeux ?
Quand aux identités, nous aurons toujours nos propres identités de notre coté, on se servira de BrightID uniquement pour vérifier que l’identité créer est bien une personne physique vivante et qui n’a pas déjà un compte membre.

Je ne voit pas en quoi cela poserait problème dans le sens ou les nouveaux membres de Ğ1 devrons toujours faire la démarche de s’inscrire à la Ğ1 après s’être inscrits sur BrightID. Ils exprimeront donc clairement leur intention de rejoindre une monnaie libre.

En tout les cas leur système a du potentiel et il me semble que nous devons creuser davantage cette possibilité afin de prendre une décision.

Peut tu définir “système externe” ? BrightID est comme pour nous un logiciel libre porté par une infra décentralisé d’humains volontaires, chacun d’entre nous est libre de s’y impliquer tout comme nous avons choisi librement de nous impliquer sur l’écosystème Duniter.
Si j’ai un serveur Duniter et un serveur BrightID, pour moi les autres serveurs sont externes, qu’il s’agisse de serveurs Duniter ou de serveurs BrightID.
Et puis en cas d’évolution trop différente ou peut toujours forker le logiciel pour qu’il continue de répondre aux besoins d’une Monnaie Libre.

2 Likes

BrightID est externe à Duniter, et inversement.

1 Like

Stéphane, j’ai essayé de retrouver ton résultat, que je trouve important, à partir de l’étude que j’avais faite sur l’évolution de la masse monétaire M lorsque la taille N de la toile de confiance varie :

Ce que j’obtiens confirme ton affirmation :

En effet, en régime stationnaire, j’avais obtenu que la masse monétaire moyenne en relatif :
CMDef
était égale à :
CMVal
c est le taux de croissance de la monnaie et a celui de la toile de confiance.

En inversant ce résultat, on obtient :
CMCM
ce qui est l’expression de la croissance de la monnaie. On voit donc, effectivement, que cette croissance augmente avec le taux de croissance a de la toile de confiance (et aussi avec c, bien sûr).

2 Likes

Dès lors que pour une donnée connue du protocole, son authenticité n’est pas assurée par lui, alors celle-ci provient d’un système externe : c’est-à-dire d’un autre protocole.

Ainsi si Duniter introduit la notion de “BrightID” mais sans en définir les règles d’authentification, alors ce BrightID provient d’un système externe. Par contre si Duniter intègre totalement le protocole BrightID dans son propre protocole, alors il ne s’agit plus d’un système exerne mais juste du système Duniter, nouvelle mouture.

Inversement : les identités créées par les utilisateurs de Duniter ne proviennent pas d’un système externe, car toutes les règles nécessaires et suffisantes permettant d’établir leur authenticité son gérées par le protocole Duniter.

Une solution type “oracle” est en fait un pont vers un système externe.

À la condition que Duniter référence BrightID, et inversement.

Car sinon on n’a pas de système exerne, on a juste le protocole dans lequel on se place et depuis lequel on observe. Si Duniter ne référence pas BrightID alors tout simplement BrightID n’existe pas, de son point de vue.

Je cite @elois sur ce point avec lequel je suis plutôt en phase.

  • Les enjeux de BrightID sont les mêmes (avoir une identité unique par personne).
  • Les moyens diffèrent (ils s’appuient sur Ethereum).
  • Duniter aura toujours ses identités en interne
  • Le seul risque serait que la politique de reconnaissance des identités de BrightID ne nous convienne plus (par exemple, la manière dont sont créés les seed-groups). Dans ce cas, il faudrait des moyens de “forker” tout en continuant de faire tourner la monnaie.
1 Like

L’enjeu de Duniter n’est pas de créer des identités. C’était le sens de ma remarque.

Oui mais plus authentifiées par lui. Ce qui introduit en fait une faille.

Passer par un système externe c’est comme découper une grosse fonction en plus petites : chaque fonction est alors plus simple, mais délègue la responsabilité à la fonction appelante. En l’occurrence, Duniter délèguerait la responsabilité des identités à un Oracle et BrightID.

Ce qui est une faille. Possiblement acceptable et même nécessaire vis-à-vis de l’objectif fixé certes, mais une faille quand même.

Une faille, je trouve le mot fort, même si je comprends bien ce que tu veux dire.

S’appuyer sur BrightID apporte 3 risques selon moi :

  • Que les développeurs de BrightID changent leur politique d’authentification et qu’elle ne nous convienne plus
  • Qu’une faille ou un bug soit présente dans le code/protocole de BrightID
  • Qu’une faille ou un bug soit présente dans l’interface entre BrightID et Duniter (l’Oracle)

Ces trois risques me semblent limitables par une simple mesure de “débranchement” de BrightID en cas de problème. Ça empêcherait Duniter de prendre en compte le flux d’humain temporairement, le temps de trouver une solution.

En contre-partie, je vois plusieurs avantages :

  • S’appuyer sur un système qui se spécialise dans la reconnaissance d’identité uniques
  • Simplifier le code de Duniter et donc les contributions
  • Se concentrer sur les problèmes monétaires

Dans tous les cas, si ça devait être réalisé, il faudrait d’abord passer par une période de test intense. BrightID aurait besoin d’être mis à l’épreuve. Peut-être même qu’il faudrait le faire avec une monnaie Ğ2, orientée “international via BrightID”.

Pour garder la compatibilité entre un code Ğ1 (WoT) et Ğ2 (BrightID), il faudrait que Duniter s’appuie sur une interface. Cette interface pourrait soit pointer sur la WoT, soit sur BrightID, soit sur autre chose.

4 Likes