Machine à état et réponses prouvées des noeuds aux clients ?

[Inso]

@nanocryk

Aie aie aie, je ne pense pas non. Avec 600 membres, chaque jour le nombre d’UTXO va augmenter de 600 ? Avec 10 000 membres, +10 000 par jour ? Quand le bloc est marqué comme produisant le DU, on peut mettre à jour les “UD non dépensés” ce qui est fait de manière atomique dans un bloc.

C’est un faux problème imho, l’UTXO devrait croitre beaucoup plus vite que l’UUDO de toute manière dans une économie où ça circule

@nanocryk

Quand aux utilisateurs qui veulent utiliser leurs DU, ils ne doivent en aucun cas donner le hash dans l’arbre, seulement la quantité qu’ils veulent dépenser. Les noeuds peuvent ensuite vérifier qu’il a assez dans ses “UD non dépensés”, valeur qui est consensuelle et connues par tous car elle figure dans le Merkle tree et est a tout moment vérifiable.

Bon après, on peut envisager que quand on dépense des UD, on ne précise pas de source, juste “je prends N unités depuis mon stock d’UD”. @cgeek qu’est-ce que tu penses de cette approche ? Tu l’avais peut-être déja envisagé, tu as probablement un avis là dessus…

@nanocryk

En effet, même si tu noterais que ça servira juste pour structurer le Patria tree, mais que son contenu (des hashs) doit rester les hashs optenus depuis ses enfants (sinon on pert tout interet des Merkle tries). Sinon, l’UID est un hash des différentes informations uniques du membre, donc il fait la même taille.

Il y a probablement plus de sections communes dans des UID écrit par des humains que dans des hash aléatoires. C’est d’après moi l’intéret d’utiliser les UID pour structure l’arbre (ça réduit le nombre de noeuds).

@nanocryk

C’est ce que j’ai appliqué dans la branche truths tu remarqueras J’ai bien été cherché mes radix tries quelque part

Oui alors j’ai beau relire, je pense que le changement de base me perturbe beaucoup trop et je comprends toujours pas comment tu l’envisages Il manque une conversion imho de la base 16 vers la base 4 du document pour bien comprendre.

ach document is stored in a subdirectory based on the sequences of 4bits (0-7) 
a document starting with 0x4b3d could be stored in <U+202D>4/5/4/7/5.

@nanocryk

Yeap, mais il va falloir faire attentions à quelques trucs : est-ce qu’on utilise le set des UID connus pour générer cet arbre ? Est-ce qu’il y a un nombre de niveaux maximal ?

Pour l’optimisation de l’arbre, je ne pense pas qu’il y ait de travail particulier si on s’appuie sur les Patricia Merkle Tree. D’ailleurs, ils disent eux même dans la spec ethereum :

provide the holy grail of O(log(n)) efficiency for inserts, lookups and deletes, and are much easier to understand and code than more complex comparison-based alternatives like red-black tries.

Ce qui est amplement suffisant. Il me semble que pour construire ces arbres, ils utilisent des éléments triés en fonction des clés (pour favoriser la construction de sous-sections).

Par contre, pourquoi est-ce qu’on garderait des non-membres dans l’arbre déja ?

@nanocryk

Je vois qu’on commence à être sur la même longueur d’onde, c’est cool

Yes, j’ai encore quelques doutes sur les attaques par omission (comment un client, qui n’a comme information qu’un UID, peut être certain que le noeud ne lui ment pas quand il dit "pas de preuve de merkle possible, UID inconnu). Je ne suis même pas certain qu’on puisse se défendre contre un tel cas

[nanocryk]

@Inso

C’est un faux problème imho, l’UTXO devrait croitre beaucoup plus vite que l’UUDO de toute manière dans une économie où ça circule

Ce n’est pas parceque l’un va augmenter que l’autre doit augmenter aussi, surtout quand il y a une solution qui permet de l’éviter.

@Inso

Bon après, on peut envisager que quand on dépense des UD, on ne précise pas de source, juste “je prends N unités depuis mon stock d’UD”. @cgeek qu’est-ce que tu penses de cette approche ? Tu l’avais peut-être déja envisagé, tu as probablement un avis là dessus…

Exactement, et du coup ça fait beaucoup moins d’infos a stocker, et moins d’infos pour dépenser.

@Inso

Il y a probablement plus de sections communes dans des UID écrit par des humains que dans des hash aléatoires. C’est d’après moi l’intéret d’utiliser les UID pour structure l’arbre (ça réduit le nombre de noeuds).

D’accord, tu parles des username, ça me va.

@Inso

Par contre, pourquoi est-ce qu’on garderait des non-membres dans l’arbre déja ?

@Inso

Yes, j’ai encore quelques doutes sur les attaques par omission (comment un client, qui n’a comme information qu’un UID, peut être certain que le noeud ne lui ment pas quand il dit "pas de preuve de merkle possible, UID inconnu). Je ne suis même pas certain qu’on puisse se défendre contre un tel cas

Pour ne pas avoir d’omission sur “machin a perdu son status de membre”. Tous membre qui est parti resterais enregistré pendant un certain temps pour qu’on puisse demander s’il y est ou pas, ce qui éviterais l’omission (tout le monde sait que le membre est toujours enregistré car il est dans la liste, et du coup un noeud qui ne donnerais pas serait considéré comme malveillant). En fait, toute donnée qui doit être supprimée doit encore être présente un certain moment pour éviter les attaque par omission.

@Inso

Oui alors j’ai beau relire, je pense que le changement de base me perturbe beaucoup trop et je comprends toujours pas comment tu l’envisages Il manque une conversion imho de la base 16 vers la base 4 du document pour bien comprendre.

Base 16 = 4 bits d’information
Base 4 = 2 bits d’information

La dans les exemples on a pris la base16/4bits car c’était simple à voir avec les valeurs en hexa.
Après en pratique fournir 16 hashs par niveau me semble beaucoup, et c’est pour ça que je prefererais utiliser de simples arbres binaires triés accompagné d’une liste complète des items stockés.

[Inso]

@nanocryk

Pour ne pas avoir d’omission sur “machin a perdu son status de membre”. Tous membre qui est parti resterais enregistré pendant un certain temps pour qu’on puisse demander s’il y est ou pas, ce qui éviterais l’omission (tout le monde sait que le membre est toujours enregistré car il est dans la liste, et du coup un noeud qui ne donnerais pas serait considéré comme malveillant).

Ok, ça protège contre une omission, pas forcément contre toutes. Mais c’est déja ça.

On peut considérer que le “non-membre” reste dans l’arbre jusqu’à expiration de l’identité pour non-renouvellement. Dans la version actuelle, 1 an après le non-renouvellement d’une adhésion, l’identité est automatiquement révoquée. Ça me semble assez cohérent comme approche il me semble.

[nanocryk]

Oui en effet. Pour les autres attaques, il faut les définir, et rajouter des preuves dans l’arbre

[Inso]

Il y a toujours le problème du client qui ne sait pas si tel UID est membre ou non, il ne peut pas savoir si le noeud lui ment ou pas (puisqu’il ne sait pas si l’UID est dans l’arbre ou non).

Mais c’est cette attaque qui me semble insoluble.

[nanocryk]

@Inso

Il y a toujours le problème du client qui ne sait pas si tel UID est membre ou non, il ne peut pas savoir si le noeud lui ment ou pas (puisqu’il ne sait pas si l’UID est dans l’arbre ou non).

Mais c’est cette attaque qui me semble insoluble.

J’ai déjà répondu à cette attaque là. Il y a toujours au même chemin un document qui liste tous les membres stockés dans l’arbre en (uid, username, pubkey), et qui est mis à jour si un nouveau membre entre ou qu’un non-membre sort de la periode de conservation.

[Inso]

Mais ceux pas encore membres ?

[nanocryk]

Ceux pas encore membre ne sont pas membre, donc ils ne sont pas dans ce document. Pas d’omission la dedans. Tous les membre sont dans ce documents (même ceux qui sont partis “il y a peu”), et cette information est contenue dans ce seul document qui est obligatoire et vérifié pour qu’un bloc soit valide.

[Inso]

Erf, on tourne en rond

Ma question est : un client sait qu’une identité était en cours d’adhésion. Il requête la chaîne de bloc pour connaître l’état de l’identité : un noeud peut lui répondre qu’il n’est toujours pas membre par omission alors que ce n’est pas le cas.

[nanocryk]

@Inso

Ma question est : un client sait qu’une identité était en cours d’adhésion. Il requête la chaîne de bloc pour connaître l’état de l’identité : un noeud peut lui répondre qu’il n’est toujours pas membre par omission alors que ce n’est pas le cas.

Non. S’il n’est toujours pas membre, il n’est pas dans ce document, ce qui prouve qu’il n’est pas membre.
S’il devient membre (par 5 certifications valide), alors le bloc ne peut être valide que si ce membre est rajouté à la liste. Cette liste n’a meme pas besoin d’être partagée dans la publication de bloc, chaque noeud peut rajouter le nouveau membre dans cette liste, et vérifier que le nouveau hash correspond. S’il ne correspond pas, c’est que la liste n’est pas valide, et donc que le bloc ne l’est pas.

Ce genre d’informations sont stockés dans l’état t, qui est connu de tous les membres par récursion avec les blocs précédents. Dans la partie transformation, le nouveau membre et les 5 certifications apparaissent. Si le noeud le met dans son bloc, elles doivent être appliquées. Tout le monde appliquent ces transformation, et si tout le monde suivent les mêmes regles, alors ils obtiennent le meme hash. Si le createur du bloc donne un hash différent, c’est qu’il n’a pas respecté les regles, et le bloc est ignoré.

Document de l’état t (avant l’entrée du membre) :

alice membre depuis 56 blocs
bob non membre depuis 18 blocs

Transformation :

carole deviens membre avec ces 5 certifications (tous les documents sont signés)

Document de l’état t+1

alice membre depuis 57 blocs
bob nom membre depuis 19 blocs
carole membre depuis 1 bloc

Si les noeuds vérificateurs retrouvent le meme document (via son hash), il est valide, sinon il ne l’est pas. Impossible de tricher la dedans, et du coup impossible de répondre par omission vu que la liste des membres est contenue dans 1 seul document obligatoire dans un bloc, toujours au même endroit. Si un noeud répond par omission de ce document obligatoire, il est forcement malveillant, on l’ajoute à une liste d’ignore et on demande a quelqu’un d’autre. Il est donc impossible de tricher sans être détecté comme malveillant.

Edit : en notant le nombre de block aussi pour les membres actif, cela permet de directement intégrer la durée de vie des identité. Si ce nombre dépasse la durée d’un an, il n’est plus membre. Si elle depasse 2 an, le compte est automatiquement révoqué (comme dans les règles actuelles) et l’identité peut être supprimée de la liste.

[elois]

@Inso

Quand aux utilisateurs qui veulent utiliser leurs DU, ils ne doivent en aucun cas donner le hash dans l’arbre, seulement la quantité qu’ils veulent dépenser. Les noeuds peuvent ensuite vérifier qu’il a assez dans ses “UD non dépensés”, valeur qui est consensuelle et connues par tous car elle figure dans le Merkle tree et est a tout moment vérifiable.

@Inso

Bon après, on peut envisager que quand on dépense des UD, on ne précise pas de source, juste “je prends N unités depuis mon stock d’UD”. @cgeek qu’est-ce que tu penses de cette approche ? Tu l’avais peut-être déja envisagé, tu as probablement un avis là dessus…

Il me semble essentiel, lorsqu’un client créer un document transaction, qu’il puissent choisir lui-même quels sources de DU il dépense. Sinon il est possible d’attaquer le réseau par dépense des mêmes DU, et le réseau forkera super facilement.
Avec le système actuel, un noeud peut refuser d’entrée un document tx demandant a consommé des DU qui sont déjà bloquer pour une autre TX en piscine (je ne suis pas sur que ce soit effectivement fait dans le code actuel mais ce serait facile a rajouter avec le protocole actuel).

Je suis de l’avis d’inso sur l’importance de stocker les DU sous forme de source UUDO.
Et concernant la base je n’ai pas compris quel était votre problème ? Une tx peut sans problème contenir des inputs de base différente donc pas besoin de “mettre a jours” les anciennes sources de DU, qu’est ce que je rate ?

@nanocryk

en notant le nombre de block aussi pour les membres actif, cela permet de directement intégrer la durée de vie des identité

Alors attention, le nombre de bloc ne correspond pas a une durée, la blocckhain pouvant avancer a des rythmes très variables selon les aléas notamment en cas de fork. Il faut et il suffit de stocker le blockstamp de création de l’identité, c’est ça qui fait fois pour l’expiration du membership (qui correspond a 1 an après la création du document identité, pet non pas 1 an après l’écriture en blockchain attention !!).

[nanocryk]

@elois

Il me semble essentiel, lorsqu’un client créer un document transaction, qu’il puissent choisir lui-même quels sources de DU il dépense. Sinon il est possible d’attaquer le réseau par dépense des mêmes DU, et le réseau forkera super facilement.

Pas besoin de noter les sources si les DU sont seulement 1 nombre par membre. Aucun risque de fork non plus, c’est l’unique source possible. Et je ne vois vraiment pas l’interet de rajouter tout les jours n sources avec n le nombre de membre, c’est du gastipillage de place et de ressources.

@elois

Et concernant la base je n’ai pas compris quel était votre problème ? Une tx peut sans problème contenir des inputs de base différente donc pas besoin de “mettre a jours” les anciennes sources de DU, qu’est ce que je rate ?

On parlais de la base du radix dans les Patricia tries, rien a voir avec la base des values monnétaires.

@elois

Alors attention, le nombre de bloc ne correspond pas a une durée, la blocckhain pouvant avancer a des rythmes très variables selon les aléas notamment en cas de fork. Il faut et il suffit de stocker le blockstamp de création de l’identité, c’est ça qui fait fois pour l’expiration du membership (qui correspond a 1 an après la création du document identité, pet non pas 1 an après l’écriture en blockchain attention !!).

Je sais, c’était juste un exemple d’usage pour illustrer mon propos.

[elois]

@nanocryk

Pas besoin de noter les sources si les DU sont seulement 1 nombre par membre. Aucun risque de fork non plus, c’est l’unique source possible.

Du coup ça limite, si je veut émettre plusieurs tx en même temps, (dans la pratique a terme ce sera un usage courant, je vais chez différents commerçants au même moment au même endroit, je les payent tous a intervalle très très proche).

Il faudra que le client fasse des tx chainés a chaque fois pour utiliser la nouvelle source résultante, c’est possible mais ça complique vachement le codage coté client…

@nanocryk

On parlais de la base du radix dans les Patricia tries, rien a voir avec la base des values monnétaires.

Je parlais de ça :

@nanocryk

Quand le bloc est marqué comme produisant le DU, on peut mettre à jour les “UD non dépensés” ce qui est fait de manière atomique dans un bloc

Mais maintenant je comprend que tu parle de mettre a jour l’unique source UUD0 par membre ?

[nanocryk]

@elois

Du coup ça limite, si je veut émettre plusieurs tx en même temps, (dans la pratique a terme ce sera un usage courant, je vais chez différents commerçants au même moment au même endroit, je les payent tous a intervalle très très proche).

Il faudra que le client fasse des tx chainés a chaque fois pour utiliser la nouvelle source résultante, c’est possible mais ça complique vachement le codage coté client…

Le membre décide combien il veut prendre dans sa réserve d’UD, et peut faire 2 transactions parallèle qui prennent 10 et 20 G1, la source d’UD va donc baisser de 30.

@elois

Mais maintenant je comprend que tu parle de mettre a jour l’unique source UUD0 par membre ?

Exact, a chaque DU on rajoute a ce compteur, et a chaque dépense on le déduis

[elois]

@nanocryk

Le membre décide combien il veut prendre dans sa réserve d’UD, et peut faire 2 transactions parallèle qui prennent 10 et 20 G1, la source d’UD va donc baisser de 30.

Alors attention avec les transactions parallèles, il faut toujours avoir en tête que le réseau est incomplet et incohérent, donc ça peut être le bordel. Je ne saurais pas la te sortir un scénario d’attaque mais j’ai un mauvais pressentiment avec cette histoire de DUs source unique

[nanocryk]

@elois

Alors attention avec les transactions parallèles, il faut toujours avoir en tête que le réseau est incomplet

En bloc non. Si un noeud vois 2 transactions et qu’elles consomment plus que possible, alors une seule peut rentrer.

[Inso]

En pratique il me semble que ça risque même de réduire les situations de fork. Possibilité de double dépense des sources à DU uniquement lorsqu’on dépensé plus que ce qu’on possède en plusieurs TX.

[elois]

@nanocryk

En bloc non. Si un noeud vois 2 transactions et qu’elles consomment plus que possible, alors une seule peut rentrer.

Je suis au courant \o/ Je parle d’avant l’écriture en blockchain évidemment…
Certains nœuds n’en verront qu’une, et pas forcément la même, d’autres aucunes.

[nanocryk]

@elois

Je suis au courant \o/ Je parle d’avant l’écriture en blockchain évidemment…

Certains nœuds n’en verront qu’une, et pas forcément la même, d’autres aucunes.

Je ne pense pas que ça pose problème. Les noeuds ne doivent pas considérer une source consommée tant qu’elle n’est pas en block. Quand ils voient un nouveau block valide, ils se rebase dessus, et la transaction incriminée est maintenant invalide.

[elois]

oui enfin pas plus de problèmes qu’actuellement bon ok