C’est encore plus compliqué avec une “simple API REST”. Chaque noeud va appeller cette API vers un BrightID, pouvant répondre quelque chose de différent à chaque fois, et dont le resultat peut changer au court du temps. Comment est-ce que l’on peut avoir un consensus sur ça ?
On ne peut pas, et c’est bien pour ça que le domaine des oracles est interessant : il permet justement de se mettre d’accord sur un élément exterieur. Ici chaque membre participant fait une requete à l’API REST de BrightID et poste son vote à l’oracle. S’il y a plus de X% de votes identiques, on peut considérer la réponse comme fiable et s’en servir pour la monnaie. Tu remplace cette API REST par un logiciel ou un module gérant la WOT, un “noeud BrightID directement” ou un autre système, l’oracle reste le même.
On a donc bien un système générique permettant de faire un pont avec BrightID, tout en permettant dans un premier lieu d’externaliser les calculs de la WOT.
Il n’y a pas urgence à migrer sur BrightID non plus
Pour moi, la première étape est de modulariser la gestion des identités au sein de la blockchain.
Une solution possible, comme proposé par @nanocryk, est d’intégrer la racine d’un arbre de merkle de la liste des membres dans la chaine.
Cette racine étant un hash, elle peut être compatible quelque soit le système sous-jacent : il suffit de trouver une construction sous la forme d’un arbre de merkle listant les membres.
On ajoute un champs “membersMerkleRoot” dans chaque bloc.
Avec Duniter en mode BrightID :
les noeuds requêtent une racine de merkle si BrightID est capable de la fournir, sinon ils requêtent une liste dont ils fabriquent un arbre de merkle et génèrent un merkle root (beaucoup moins optimal).
Avec Duniter en mode WoT :
Soit on génère 2 blockchains en parallèle. La blockchain qui gère la monnaie fait référence à la blockchain qui gère la WoT via ce membersMerkleRoot.
Soit on garde la blockchain standard, et on ajoute un champs “membersMerkleRoot”. Cette méthode me semble moins propre (les blocks contiennent des données différentes suivant le système de gestion des identités sous-jacent). Mais potentiellement c’est plus simple à réaliser.
Dans chaque cas :
Un noeud, lorsqu’il calcule un bloc, doit inclure une preuve de merkle pour montrer que sa clé correspond à un membre
Lors de la consommation des DU, le client doit inclure une preuve de merkle pour montrer que sa clé correspond à un membre à la date du bloc du DU généré
Est-ce qu’il existe d’autres actions qui nécessiteraient de prouver qu’on a une clé membre ?
C’est surtout que définir “API REST” dans un protocole non-réseau est super difficile (je pense même que c’est impossible, c’est pour ça que je te demandais des détails sur l’idée que tu avais), alors que définir un Oracle non, c’est “facile” ou à tout le moins “possible”.
Moins optimal, mais permet de se plugger directement sur BrightID sans le modifier, ce qui est pas mal. Et quand on voit le nombre de Hash/s de nos machines, c’est plutôt négligeable tant qu’il n’est pas fait trop souvent (4 synchro par jour par exemple).
Les 2 blockchains me semblent plus simple, et évite d’avoir un doublon d’information ainsi qu’une généricité.
Yeap, ainsi que :
quand un nouveau membre publie ses 5 certifications, il doit donner la preuve de membre de ses 5 certifieurs.
quand une certification vers un membre existant à lieu, la preuve de Merkle des 2 comptes doit être fournie.
BrightID et WOT sont similaires dans leur construction d’une base de données d’identités décentralisée et non intrusive. Ce qui fera la différence seront les API qui seront mises à disposition pour être compatible avec les solutions d’authentification actuelles (oAuth, LDAP, …)
Un service d’authentification décentralisé et libre est un indispensable pour contrecarrer les OneID privatifs qui vont vouloir s’imposer… Votre trousseau de clef sera détenu pour vous par votre banquier ou par vous même? Quels seront les membres libres qui se joindront à la réalisation de cette mission?
