En effet il me semble que dans le cadre de la monnaie libre vous pourriez simplement économiser l’électricité en faisant de “la proof of membreship”, c’est à dire en tirant au sort parmi tous les membres qui on des noeud actifs, le(s) prochain(s) à valider un block via un protocole de “multi-party coin tossing” ( https://eprint.iacr.org/2012/643.pdf ), non?NON, VOIR LE second post pour une meilleur proposition.
Vous avez cet avantage par rapport à quasi-toutes les autres crypto d’avoir un statut de membre supposé identifié une personne unique. La POW et la POS ont été inventé précisément pour palier à l’impossibilité d’identifier une personne unique sur le réseau.
En fait en y réfléchissant, on pourrait même complètement retirer la notion de tirage au sort, et la remplacer par une notion de “chacun son tour”, si l’on considère que l’on ne peut pas changer rapidement et facilement l’adresse publique d’un membre.
On pourrait dire “to be valid, the Block must contain an hash of the time t1 since epoch in micro/milli-second, which has a common substring of at least certain size NB_SUB with the public key of the member validating the block. To be condisidered valid t1 may not be lower than the last block’s t0 and may not be larger than current real time” NB_SUB est adapté au fur et à mesure du temps.
[edit]: (remarque: il faudrait peut-être réfléchir à ajouter un SALT au hash , qui changerait de manière aléatoire/imprévisible dès qu’il y a un nouveau membre, pour éviter que quelqu’un ne choisisse son adresse public pour correspondre à un motif prévisible à long terme dans le temps)
Il faut aussi ajouter une possibilité de “punir” celui qui ajoute un block derrière un block d’une chaîne concurrente (fork) afin de forcer au consensus, et éviter que les validateur ne misent sur toutes les branches en parallèle. Pour cela on peut imaginer, que les validateurs de block ai le droit de s’approprier pendant un certain temps le DU de quelqu’un dont on peut prouvé qu’il a signé un block sensé suivre un block qui n’existe pas dans la chaîne.
La première remarque est pertinente, la deuxième, j’en doute. Peut-être que replacer tes connaissances dans le domaine général de l’algorithmique répartie te permettrait de prendre du recul.
Pour cela je te conseille le cours de Rachid Gerraoui au collège de France : https://www.college-de-france.fr/site/rachid-guerraoui/course-2018-2019.htm
Je répondrais donc :
Nous n’avons effectivement pas besoin de POW, on pourrait faire autrement.
Je crois que tu aurai put réponde la meme chose à une proposition telle que celle-ci:https://bitcoin.org/bitcoin.pdf qui en soit est une proposition sortie du chapeau.
Je parlais du premier post et du second post. J’ai complété ma réponse ci-dessus. Notre système d’identité permettrait en effet de se passer de pow. Cependant le problème reste un problème d’algorithmique répartie, on ne peut pas faire n’importe quoi. Tu peux toujours avoir des défaillances réseau et des défaillances de machine.
En fait, pour ce qu’on fait, on pourrait même se passer de blockchain mais c’est une autre histoire.
Bitcoin est une preuve de concept à part entière. Pour duniter, les développeurs ont fait le choix de se tourner vers des solutions déjà éprouvées. Mais cela peut très bien changer dans le futur. Amazon travaille en ce moment sur des bases de données décentralisées sans blockchain. À suivre…
Ok merci, mais du coup je n’ai pas compris pourquoi en soit la proposition dans mon deuxième post te parait mauvaise dans l’idée, ni le rapport avec l’algorithmique répartie.
Après je dis pas qu’il faut l’utiliser tel quelle, je vient d’y penser, il y a peut-etre des raison pour lesquelles ça marche pas et très surement des améliorations. C’est à réfléchir tester. (Par exemple il faudrait peut-être ajouter un salt tous les N blocks, ou dès qu’il y a un nouveau membre, dans le hash du temps, pour éviter que quelqu’un ne choisisse son adresse public pour correspondre à un motif prévisible à long terme).
Le problème du Pow n’est pas le consomation actuelle, c’est que c’est une compétition qui pousse à consomer le plus de resource possible pour gagner et il n’y a donc pas de limite théorique à l’escalade de la consomation et en soit ça me dérange.
Avec l’algo “chacun son tour”, un nœud peut ralentir la blockchain en ne proposant pas de bloc valide avant un certain temps. On pourrait imaginer un timeout assez court pour passer au suivant. Mais si plusieurs nœuds défaillants ou complices se suivent dans la file d’attente, la blockchain reste bloquée ou est forkée sans possibilité pour les autres d’écrire ?
Le système d’exclusion et de difficulté tournante de Duniter ressemble assez à ça, mais à la différence qu’il n’y a pas un nœud à l’avant de la file d’attente, mais les deux tiers.
Pour la POW, elle permet de tirer un membre au hasard d’une manière assez fiable. On pourrait déterminer le prochain écrivain de bloc à partir du hash du dernier bloc par exemple, mais ça aurait des inconvénients :
L’écrivain d’un bloc a une part de décision sur l’identité de l’écrivain du prochain (il peut refuser de publier son bloc si il donne le droit d’écriture à quelqu’un qu’il n’aime pas).
Le hasard est ici généré par le contenu de la blockchain uniquement, il y a un risque de mauvaise distribution. (là où le hasard de la POW est généré par un ensemble de nœuds et un algo efficace)
Que faire en cas de défaillance d’un nœud ?
Ensuite, certains ont fait le calcul sur le forum, la consommation électrique de Duniter est ridicule. (T’es-tu renseigné sur la variation de la difficulté en fonction de la puissance de calcul apparente ? La difficulté varie pour permettre la même fréquence d’écriture de blocs indépendamment de la puissance de calcul, rendant la course inutile.)
Non pas dans la proposition que j’ai faite. Chacun a une chance de valider un block chacun son tour mais s’il ne le fait pas ce n’est pas grave puisqu’on adapte NB_SUB est adapté au fur et à mesure du temps pour avoir une fréquence de block moyenne correspondante à celle désirée (comme dans POW).
Ensuite, certains ont fait le calcul sur le forum, la consommation électrique de Duniter est ridicule. (T’es-tu renseigné sur la variation de la difficulté en fonction de la puissance de calcul apparente ? La difficulté varie pour permettre la même fréquence d’écriture de blocs indépendamment de la puissance de calcul, rendant la course inutile.)
Exactement comme bitcoin non? Au début c’était négligeable…
C’est bien le problème ! Quand on cherche à faire tourner un programme sur plusieurs machines, il faut s’assurer de pouvoir ramener la situation à une machine de Turing unique. Il existe plein de variantes au problème en fonction de la présence de byzantins ou de la possibilité de défaillance… Tout cela est défini de manière très précise dans le cours. On montre que le consensus (aussi défini dans le cours) suffit à résoudre le problème. La blockchain bitcoin a montré comment obtenir le consensus. Il y a d’autres manières de l’obtenir, mais il faut prouver que ton algorithme distribué le remplit bien, parce que d’expérience, il est très facile de trouver une “solution” qui n’en est pas une. De plus, le consensus n’est pas toujours nécessaire.
Par rapport à la compétition, elle n’existe pas dans duniter, puisque la création monétaire n’est pas faite en minant un bloc.
C’est comme la POW de Duniter, non ? L’écriture étant réservée à une fraction tournante des membres.
Tu peux miner de la Ğ1 avec une ferme de serveurs si tu veux, si l’algo fonctionne bien (parce qu’en pratique il ne semble pas encore tout à fait au point) tu ne mineras pas plus qu’un Raspberry Pi. C’est grâce à la difficulté qui augmente après chaque écriture, et à la fenêtre d’exclusion.
Il y a quand même des récompenses. Mais en fait vous ne pouvez pas dire la puissance de calcul utilisé pour le POW va rester faible et c’est très bien comme ça. Si elle reste faible, la POW apporte une faible sécurisation au réseau, et dès lors que la valeur potentielle du réseau deviens suffisamment grande, un hacker mettra l’argent sur la table pour avoir une grande puissance de calcul et hacker le réseau.
Ca s’est d’ailleurs passé dans les débuts de bitcoin ou la puissance de calcul totale du réseau était faible:
Dans l’esprit la sécurisation par POW implique nécessairement que la quantité totale de puissance de calcul du réseau augmente en proportion de la valeur à sécuriser.
Non car tu n’as pas à calculer des Téra-hash par secondes pour rien, tu as juste à calculer un hash toutes les ms, du temps au fur et à mesure qu’il s’écoule et voir si c’est ton tour, ce qui représente une quantité de travail fiable et qui n’augmentera pas dans le temps.
La différence est que j’utilise le hash du temps, mais aussi que je le compare à la clef publique du compte membre qui veut signer le bloque pour determiner que c’est à son tour d’avoir l’opportunité de valider un block. Et donc que j’utilise la preuve que ce compte membre correspond à une personne physique et ne peut pas changer d’adresse publique tous les 4 matins. Donc ce n’est pas le la “proof of work” mais de la “proof of membership”
À moins que tu fixes un Δt minimum, la probabilité de trouver le bon hash dans une durée donnée augmente avec la puissance de calcul. Il est également possible de calculer le hash du temps à l’avance si tu as assez de puissance. C’est donc toujours une PoW. La PoM est un mécanisme séparé, ne faisant que relier une clé publique à la WoT.
Oui il faut fixer un Δt raisonable de telle manière que la puissance nécessaire en terme de hash/seconde reste négligeable, c’est pour ça que j’ai mis miliseconde/microseconde, mais il faut effectivement choisir une fois pour toute et le fixer.
Dans Duniter la PoW est utilisée comme tirage aléatoire borné dans le temps, qui permet d’assurer deux choses essentielles :
1°) permettre à tous les noeuds de la fenêtre courante d’avoir une chance d’écrire un bloc, avec une difficulté faible mais non nulle (+ exclusion des clés qui trouvent trop de blocs par difficulté personnalisée).
2°) De gérer la difficulté finement afin que le temps de réussite moyen soit centré autour de 5 mn.
Gérer ces deux points n’est pas trivial, la PoW fait ce job. Donc à moins de proposer un principe qui assure ces besoins (rotation de calcul, répartition des chances, assurance d’un temps moyen), alors on ne peut pas remplacer cette solution.
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.
