Duniter utilise la POW?

J’ai précisément proposé dans mon second post, une idée sur laquelle on peut réfléchir, qui à prioris répondrait de manière simple et directe à ces deux critères. Après il faut y rélféchir pour voir s’il y aurait des failles ou non.

Tu n’as plus qu’à réfléchir et tenter de trouver :slight_smile:

1 Like

L’enjeu est ce que j’appelle la synchronisation, ou comment faire avancer de façon synchrone un système réparti.

À cet enjeu il convient de poser certaines hypothèses, pour Duniter j’ai choisi :

  • faible connectivité : on suppose que les nœuds disposent d’un faible débit de données, et d’une connexion instable (tend à être établie par intermittence)
  • les membres du réseau ne sont pas tous disponibles pour l’écriture
  • tout membre n’est pas forcément honnête, et peut aussi faire des erreurs (bugs logiciels, erreur de configuration, …)

À ces 3 hypothèses j’ai ajouté, de façon moins impactante :

  • fréquence relativement élevée (1h d’attente = trop lent)
  • capacité de traitement limitée : on suppose que le traitement d’une seule donnée décisionnelle (donnée à vocation de synchronisation) prend un temps non-négligeable

De là, certains algorithmes conviennent, d’autres moyennement, d’autres encore pas du tout.

Citons en exemples :

  • La PoW, fonctionne très bien dans ce contexte car :

    • faible connectivité OK : 1 seule trame réseau :white_check_mark:
    • membres pas tous disponibles OK : il suffit d’un seul membre :white_check_mark: (à l’exclusion près)
    • membre malhonnête/buggué OK : tant qu’il reste des membres honnêtes/conformes :white_check_mark:
    • fréquence OK : 5’ :white_check_mark:
    • capacité de traitement : 1 seul message (le bloc) :white_check_mark:
  • Algorand qui se rapproche de ce que tu évoques @pparent76, mais :

    • dont la crypto sous-jacente est très récente et peu éprouvée :warning:
    • suppose une connectivité élevée en cas de divergence sévère :no_entry_sign:
  • Ma proposition initiale, basée sur FBA :

    • suppose une connectivité élevée :no_entry_sign:
    • membre malhonnête/buggué : comment gérer les multiples avis ? :no_entry_sign:
    • capacité de traitement limitée : potentiellement de nombreux échanges :no_entry_sign:

Je t’invite à lire ces deux sujets sur Algorand et FBA, tu y trouveras pas mal d’informations sur le cheminement de Duniter.

4 Likes

Si je prend la proposition dans mon second post et pas celle de mon premier post à prioris:

  • faible connectivité OK : 1 seule trame réseau nécessaire :white_check_mark:
  • membres pas tous disponibles OK : il suffit d’un seul membre :white_check_mark:
  • membre malhonnête/buggué OK : tant que la majorité des membres son honnetes le réseau est OK :white_check_mark:
  • fréquence OK : réglable à souhait en adaptant NB_SUB comme avec la POW :white_check_mark:
  • capacité de traitement : 1 seul message (le bloc) :white_check_mark:
  • utilisation de resources: faible :white_check_mark:

Ta proposition repose sur une définition ambiguë : “current real time”, de même pour la notion de “fork” : tout ceci n’existe pas dans le protocole, et ne saurait l’être sans faire référence a une chose qui a toutes les chances d’être différente d’un nœud à l’autre. C’est bancale.

À la limite tu pourrais te reposer sur le temps blockchain, lui est commun.

Non je ne crois pas : qu’est-ce qui empêche un tiré au sort de bafouer cette fréquence en émettant immédiatement son bloc, par exemple ? La PoW impose un tempo moyen indépendant du caractère honnête/buggué du logiciel.

1 Like

Voir aussi:

Dans ma proposition du second message il n’y a pas de tirrage au sort à proprement parler. Et il doit forcement attendre un temps t ou c’est son tour pour pouvoir émétre un block valide. Il ne peut pas le faire avant que ce temps arrive, car sinon les autres noeds vont l’ignorer. La référence de temps commune pouvant être donné par n’importe-qu’elle horloge atomique sufisament précise, et étant donc consensuelle. (En pratique si tu veux un block toute les 5 minutes la précision démandée est relativement faible).

Pour prendre un exemple si j’envois un block aujourd’hui qui est certifié pour 2020, les autres devraient l’ignorer, car on est évidement pas en 2020, de la même manière que dans le POW les autres devraient ignorer un block qui fournit un hash qui ne résout pas le problème imposé par la POW. Et quand on arrivera à 2020 il existera déjà des chaînes bien plus longues, donc le block n’aura aucune valeur.

Enfin personne n’aura intéret à capitaliser sur un tel block qui a peu de chance de faire partie du consensus, comme un block postdaté, car il risquerai de perdre de l’argent du fait des punitions décrites dans mon second post. Pour prouvé qu’il l’a fait et appliquer la punition, il suffira tout simplement de publier le block signé qu’il a produit pour une autre branche dans la blockchain de cette branche.

Je ne vois toujours pas la différence.

Avec la PoW, toutes les Δt s je calcule le hash avec pour sel un nombre n que j’incrémente de 1. Si le hash commence par au moins x zéros, j’envoie mon bloc et je mets n à zéro.

Avec ce nouveau système, toutes les Δt s je calcule le hash avec pour sel un nombre t que j’incrémente de Δt. Si le hash contient x bits de ma clé publique, j’envoie mon bloc.

Que la regex du hash demande des zéros ou une portion de la clé publique ne change rien, puisque chaque bit du hash est idéalement équiprobablement 1 ou 0. On pourrait utiliser n’importe quelle regex, mais compter les bits 0 au début ou à la fin est toujours le plus simple (à vérifier et pour calculer les probabilités).

1 Like

@ 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.