BrightID - Identité unique décentralisée

BrightID propose un système de reconnaissance d’identité décentralisé. Dans leurs objectifs techniques, comme pour Duniter, ils ont pour souhait d’empécher les attaques sybilles et de limiter les inscriptions à une identité par personne.

Peut-être qu’un jour, on pourra externaliser la WoT de Duniter pour utiliser celle construite au sein de BrightID. En attendant, il y a surement pas mal de choses à apprendre sur leur fonctionnement interne.

7 Likes

Tu saurais résumer leurs idées ?

  • Pas de limite de distance à première vue, tout s’appuie sur la connectivité (mais on va voir plus bas que la distance apparait dans les algos, sans être limitée en dur)
  • Les utilisateurs ont des “Trust Score”, si il est trop bas, ils sont considérés “sybils”
  • Les groupes ont des “Trust Score”, qui contribuent au “Trust Score” des membres du groupe
  • Pour avoir un “Trust Score”, un utilisateur doit d’abord rejoindre un groupe. Un groupe doit avoir une connectivité interne élevée (De 50 à 100%, ce sont les créateurs du groupe qui décident).
  • N’importe qui peut créé un groupe, il faut être au moins 2

C’est en gros leur mécanisme de défense anti sybil : les sybils, créateurs de sybils et leurs collaborateurs vont devoir se grouper entre eux, puisque les utilisateurs honnêtes refuseront de se grouper avec eux

  • Des groupes “seed” sont créés. Ces groupes “seed” sont créés par des utilisateurs 100% de confiance (n’importe qui ne peut pas les créer). La confiance va se diffuser des groupes “seed” vers les groupes créés par les utilisateurs en fonction de l’algo ci-dessous. Se pose la question de la gouvernance de création des groupes seed, c’est abordé dans le papier.
  • Une notion de “force de connexion” entre les groupes permet de détecter des “groupes de groupes”. La “force” d’un groupe A vers un groupe B est le nombre de connexion de A vers B divisé par le nombre de membres dans A et B.
  • Un petit algo itératif est mis en place pour détecter des groupes de groupes. On défini un niveau de force minimum en deça duquel les groupes ne peuvent pas former de sur-groupe.
  • L’algo est le suivant :
    • Chaque groupe calcule la force de ses connexions
    • Pour chaque groupe, on sélectionne la connexion la plus forte (tant quelle est au dessus du niveau minimum requis)
    • Si la connexion inverse existe, on créé un surgroupe
    • On réitère ceci pour chaque surgroupe généré ainsi que pour chaque “Seconde connexion la plus forte”
    • Lorsqu’un groupe rejoint un surgroupe contenant un groupe “seed”, il obtient comme score de force le niveau de force de connexion minimum utilisée pour cette qualification
  • La force ainsi que les surgroupes sont calculés pour différents niveaux de force minimum. Le trust score d’un groupe dépend du niveau de force pour lequel un groupe se qualifie lorsqu’il forme un sur-groupe. On prend le niveau de force le plus élevé pour déterminer son trust score.

Globalement c’est intéressant, ça ressemble pas mal à ce qu’on fait côté Duniter avec la notion de distance et de % de membre sentries à joindre. Eux ils n’inventent pas grand chose, et s’appuient plutôt sur l’état de l’art dans la recherche anti-sybil (ils référencent 6 papiers). Ils combinent en fait les différents papiers pour aboutir à un système conçu pour la reconnaissance d’identité unique.

9 Likes

Hello,
Un peu hors sujet mais pas tout à fait, je pose ça ici : https://www.gravity.earth/#digital-id

Our mission is to allow anyone to create a secure, self-sovereign digital ID based on personal data. On the fly, using any mobile phone on the market, no matter the telecom operator or type of phone.

New whitepaper for BrightID.

3 Likes

Ce que je ne vois pas dans leur système, et qui me semble utile/nécessaire :

  • un système d’inertie pour éviter les effondrements de confiance (il y a peut-être derrière le système itératif, mais je n’en ai pas identifié la temporalité)
  • un mécanisme pour éviter que les mort reste des identités unique actives / pour sortir les cybil qui ont déjà mis un pied dans la porte.

Et effectivement, plus de lumière sur la partie seed.

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