Duniter utilise la POW?

@ tuxmain
Avec la POW plus je calcule de hash plus j’ai de chance de certifier un block

Avec la POM (proof of membership) telle que décrite au dessus, j’ai juste besoin de calculer un nombre faible donné (et n’augmentant pas dans le temps avec les capacité des processeurs) de hash par exemple 1000h/s et augmenter la cadence n’augmente aucunement mes chances d’avoir le block. Pour chaque Δt (=1ms par exemple), il n’y a qu’un seul hash possible à faire.

Il est inutile de calculer les hashs supérieur au temps t actuel, car il seront rejeté par les autres pair, le block ne peut etre émis pour un temps t futur, voir mon post juste avant.

Ok donc tu voudrais déplacer le mécanisme de régulation de la difficulté, de la taille de la substring vers des Δt et t réglementaires, c’est ça ?

Ça paraît une alternative intéressante, on pourrait faire un réseau de test, avec un programme qui ne fait que ça, pour expérimenter.

1 Like

Ok donc tu voudrais déplacer le mécanisme de régulation de la difficulté, de la taille de la substring vers >des Δt et t réglementaires, c’est ça ?

Non Δt reste constant, ce qui varie c’est le nombre de bit commun nécessaire entre la clef publique du membre et le hash du temps t, pour lui accorder le droit au block. (tout comme dans le POW le nombre de hash/s reste constant mais ce qui varie c’est le nombre de bit nuls nécessaires).

Ça paraît une alternative intéressante, on pourrait faire un réseau de test, avec un programme qui ne >fait que ça, pour expérimenter.

Ce serait super intéressant de tester effectivement si personne ne trouve d’objection importante, d’ici là. Je vais réfléchir pour créer un tel programme.

J’ai fait ce petit programme Python qui permet de tester facilement en local différents systèmes de minage. Pour l’instant il ne fait que la PoW style bitcoin (difficulté fixe, nonce, comptage des zéros). Ça affiche le H/s et la moyenne de durée d’un bloc. Je vais ajouter un système de régulation de la difficulté en fonction de la durée d’un bloc et ton système basé sur le timestamp.

Ok merci je vais regarder ça pour l’instant je continue de réfléchir à mon candidat de nouveau système d’obtention de consensus. Je suis en train de rédiger un papier qui explique en détails comment le mettre en œuvre, pour avoir les idées claires! Je partagerai le brouillon dès que possible.

Salut @pparent76,

J’avais évoqué ce problème il y a quelques temps, utiliser PoW dans un réseau qui pourrait s’en passer, et j’avais aussi montré que c’est même une mauvaise idée car ça introduit des failles de sécurité.
Ça peut t’intéresser :

Un tirage “chacun son tour”, est une très bonne idée, il faut juste bien le spécifier et gérer les cas particuliers, et en tout cas c’est pas plus “sorti du chapeau” que l’implémentation actuelle de duniter :wink:

Tu te reposes sur du hors protocole, c’est une mauvaise idée car la donnée n’a aucune garantie d’être commune. Typiquement avoir une horloge atomique chez soi. Et quand bien même, aligner N horloges atomiques distantes dans l’espace n’a rien de trivial.

Dès que tu te sers du hors protocole, tu t’exposes à des divergences de comportement. Ce qui mène à un réseau qui tend à ne plus être d’accord.

3 Likes

On pratique ça ne pose aucun soucis d’utiliser le temps système, tous les ordinateurs ont une horloge interne, dont un décalage de quelques secondes ne pose pas de pb, et si un ordi a un gros décalage, les blocks qu’il va proposer ne seront pas acceptés.
Voir par exemple Tezos … essayez d’étudier ce qui existe déjà avant de partir dans tous les sens :slight_smile:
Une adresse est tirée au sort pour produire un block à tel moment, donc si elle le fait pas, son tour est sauté, et si elle le fait trop tot, le block est ignoré ou mis de côté en attendant.

Voici un premier brouillon expliquant le protocole que je propose:

http://crypto.omb.one/pot.pdf

Il peut s’appliquer à Duniter mais aussi à des monnaies du type bitcoin. N’hésitez pas à jetter un oeuil. Il faut réfléchir aux implications de tout ça. La partie la plus dure est le changement de salt, le reste est très simple.

Edit: la section 4.3 doit être réecrite, ça ne va pas à la reflexion. Il faut que je relise le papier du multi-party coin tossing.

N’hésitez surtout pas à me dire ce que vous en pensez!

@ ytreza tu as le papier qui explique le mécanisme de POS de la blockchain Tezos dont tu parles?

Edit: Ici il y a de la doc (qui me parait pas très complète), c’est de la delegated proof of stake
https://tezos.gitlab.io/tezos/whitedoc/proof_of_stake.html#blocks

Ceci dit, un pré-requis pour faire tourner un noeud duniter pourrait être d’être correctement synchronisé par ntp. Un noeud désynchronisé divergerait par lui même non ?

Un des points faibles de Tezos c’est leur doc qui en effet n’est pas très complète ou en tout cas pas regroupée.
Dans Tezos les producteurs de block sont tirés au sort en fonction du nombre de tezos détenus (nombre de rolls, qui valent 8000 XTZ). Voir ici pour le mécanisme de Liquid PoS.
La seed pour le tirage au sort vient des producteurs de blocks qui incluent des bits de random, grace à un mécanisme de commit/reveal: ils donnent d’abord le hash de leurs bits de randomness, et dans le cycle suivant, ils donnent les bits eux memes, comme ça ils ne peuvent pas choisir leurs bits en fonction des autres.

Dans Duniter, il suffirait de choisir un des membres aux hasard.

Oui comme j’ai mis dans mon papier. Mais ce n’est pas évident de ne pas permettre de manipuler les choses, à partir du moment ou quelqu’un peut s’abstenir ou non de reveler ce qui permet de gagner un bit de determinisme à l’attaquant (plus s’il a plusieurs participation). Je suis en train d’y réfléchir. Si tu as une solution à ce problème n’hésites pas à me dire!

Pour autant si l’on met se problème de génération de nombre aléatoire de coté, ce qu’ils proposent parait beucoup plus complexe que ce que je propose dans mon papier, pour à peu pret le même résultat.

Une solution pour mitiger la manipulation du random, c’est de faire en sorte qu’on ne tire pas au sort qui va produire le block, mais qu’on tire au sort l’ordre des membres qui vont produire les blocks, comme ça tout ce que peut faire l’attaquant c’est changer l’ordre.

PS: je vois pas en quoi tirer au sort en fonction du stake est plus compliqué que ce que tu proposes :slight_smile:

Une solution pour mitiger la manipulation du random, c’est de faire en sorte qu’on ne tire pas au sort qui va produire le block, mais qu’on tire au sort l’ordre des membres qui vont produire les blocks, comme ça tout ce que peut faire l’attaquant c’est changer l’ordre.

Ca me parait pas forcement satisfaisant, si le hasard ne sert à rien et que c’est pas grave si on peut l’attaquer, alors autant ne pas faire de hazard.

Quand je disais plus compliqué je ne parlais justement pas de la partie commit reveal, mais du reste.

Oui c’est une piste aussi, à voir si le fait que l’ordre de production des blocks soit toujours le même ne permet pas d’autres attaques.

Une attaque possible c’est que si l’ordre est toujours le meme, tu peux (dans les blockchains classiques PoS classiques, dans duniter je sais pas) diviser ton stake en plusieurs adresses et faire en sorte qu’elles soient tirées au sort consécutivement, et donc au final produire pleins de blocks à la suite, ce qui te permet de faire une attaque double spend plus facilement.

Donc il vaut mieux faire un ordre aléatoire.

1 Like

Quand je disais autant ne pas faire de hasard, ce n’était pas une proposition. C’est pour dire que pour moi s’il est nécessaire d’utiliser du hazard, il faut qu’il soit bon.

La solution sans hazard pose des problème pour l’arrivé de nouveaux membre qui peuvent choisir leur clef publique comme ça les arrange.

Je ne sais pas ce qui signifie “partir dans tous les sens”, mais si ça signifie “développer une monnaie libre quand personne d’autre ne le fait”, je crois que je préfère ce chemin.

C’est du niveau logiciel, c’est possible, mais il me semble que ce n’est pas de cela dont nous parlons. Nous évoquons le protocole ici.

Et à ce sujet je crois que je ne suis pas compris : le protocole sert à imposer des règles à ceux qui voudraient participer. Actuellement, la règle de PoW de Duniter oblige tout participant à réaliser une preuve par les moyens qui lui conviennent, Duniter est totalement agnostique de cela. Et bien entendu cette règle est pensée dans le but d’obtenir l’effet escompté : un bloc en moyenne toutes les 5 minutes pour la Ğ1.

À contrario, une règle qui dit “ne pas accepter de blocs arrivé il y a moins de 5 minutes” n’est pas imposable à autrui, car elle ne repose pas sur le protocole mais sur un système externe sur lequel on n’a pas la main.

Bref, ce type de règle introduit une nuisance possible de ceux qui ne voudraient pas respecter cette règle, là où ce n’est pas possible avec la PoW actuelle de Duniter.

2 Likes

Je ne critiquais pas le côté toile de confiance et monnaie libre, c’est tout simplement génial.
Je critiquais le reste : le mécanisme de PoW pour tirer au sort le prochain producteur de block.

C’est possible de nuire d’une manière similaire dans Duniter : tu crées des blocks alors que tu n’es pas tiré au sort (tu n’as pas trouvé de PoW) : ton block n’est pas valide, et tu occupes de la bande passante pour rien.