Alors voilà je réfléchi beaucoup a ws2p v2 en ce moment, je vais poster une RFC bientôt pour ça :wink: Mais voilà il y a une feature que j’aimerais beaucoup implémenter a ws2p v2 mais il semble que cela ne soit pas possible avec ed25519, ou alors j’ai mal compris ? J’ai besoin de l’avis de spéciali…

[image] elois: Bah si, les clients auront toujours la preuve de quel noeud est membre ou ne l’est pas. Oui, mais si un membre peut avoir 50 noeuds qui apparaissent comme membre sans pouvoir identifier à quel membre il appartient, ses noeuds pèseront 50 fois plus lourd dans les requêtes décent…

[image] Inso: Oui, mais un membre peut avoir 50 noeuds qui apparaissent comme membre. Et donc il pesera 50 fois plus lourd dans les requêtes décentralisées. Oui donc il faut trouver un moyen de reconnaitre que deux nœuds appartiennent au même membre sans savoir de quel membre il s’agit, je su…

@Inso si c’est juste pour que les clients puissent déterminer quel est le consensus réseau ils peuvent s’appuyer sur des head qui seraient toujours signés de manière classique donc on saurait toujours a quel membre appartient chaque head et chaque membre n’aurais donc toujours qu’une seule voie, qu’…

Ce n’est pas juste une question de consensus réseau. Il faut aussi que l’on puisse vérifier que quand on demande “Est-ce que tel identité est membre ?” au réseau, cette requête ne puisse pas être victime d’une attaque sybille (ou des dizaines de noeuds malintentionnés répondent une fausse réponse…) …

@Inso @nanocryk Je pense que la solution se situe coté réseau : il faudrait une api client fait de telle sorte que la réponse passe par l’ensemble du réseau, un peu comme ce que fait bma avec la commande sync mais en beaucoup plus sophistiqué, je m’explique : Les clients pourraient requeter n’imp…

Une autre solution qui viendra avec le nouveau protocole : Dans le nouveau protocole, tous les documents seront indexés dans un Merkle Tree. Un client se synchronise en ne recuperant que les headers et la preuve de travail, qui contiennent les Merkle Root, tous les documents étant segregués plus l…

[image] nanocryk: Du coup chaque request est broadcast à tous les membres du réseau ? Ca risque pas d’être assez énorme comme charge ? Non seulement aux nœuds auquel le noeud est connecté via ws2p, ensuite on peut limiter les rebond a 1 ou 2 step en fonction du nombre X de membres différents …

Le mécanisme basé sur les merkleRoot ne permet malheuresement pas de faire des requêtes avancées telles qu’on l’envisage avec GVA (Telle identité est elle membre, est-elle dans la WoT ou trop loin des sentries,e tc). Mais c’est un mécanisme intéressant pour toutes les requêtes de type “validation d…

[image] Inso: Ca risque par contre de surcharger les sockets inter-noeuds Alors en fait le plus souvent il ne s’y échange rien, sauf l’hors de l’arrive d’un nouveau bloc, mais entre deux blocs les sockets inter-nœuds sont largement sous-exploités :slight_smile: [image] Inso: Et les délai…

[image] elois: Oui il faudrait bien réfléchir a comment optimiser ça. Après dans la pratique un noeud étant connecté en moyenne a plus de 10 autres, et les membres étant prioritaires, 1 seul rebond suffirait pour voir une réponse de 6 membres différents :wink: Avec le recul, ça pose quand mê…

Duniter Forum

Ring signatures pour anonymiser les noeuds sur le réseau

R&D

ring-signatures

show post in topic

Home
Categories
Guidelines
Terms of Service
Privacy Policy

Powered by Discourse, best viewed with JavaScript enabled