@AdrienL et moi même allons effectuer une présentation technique de la Proof of Work de Duniter à l’occasion du DevFest 2019 à Nantes (du 21 au 22 octobre prochains), en particulier du mécanisme de difficulté personnalisée (handicap + facteur d’exclusion) et en quoi cela permet de réduire significativement la consommation électrique du réseau.
Afin d’avoir une idée de la consommation moyenne actuelle du réseau Duniter, nous aimerions savoir quelles sont les configurations matérielles de vos noeuds.
Vous pouvez répondre dans ce sujet pour nous communiquer vos configs.
@bpresles@AdrienL je viens de visionner votre présentation et de nombreux points sont imprécis voire incorrects, je vous prie de bien vouloir prendre en compte les remarques qui suivent pour ne pas refaire les mêmes erreurs dans d’éventuelles futures présentations
Aussi, ayez la rigueur de vérifier au préalable tout ce que vous allez affirmer, cela implique que si vous n’êtes pas sûr d’un point il vaut mieux ne rien en dire que de dire quelque chose de faux. (Et cas de question sur ce point, dites honnêtement que vous ne savez pas).
Mes retours :
NB : j’ai bien pris en compte qu’il s’agit d’un public technique et j’ai déjà exclu les points qui me dérangeaient dans votre approche mais qui ne sont pas erronés.
Diapo 3 : le mail est à ranger dans la catégorie des « réseaux décentralisés », et non « centralisés ». D’ailleurs vu votre découpage en trois types de réseaux juste avant vous auriez dû ranger les blockchains dans votre catégorie « réseaux distribués ».
D10 : La mise à jours d’une blockchain se fait par consensus et minage −> non, d’ailleurs vous dites bien juste après qu’il y a plusieurs mécanismes de consensus différents, et tous ne nécessitent pas le minage.
Le terme « miner » est incorrect : le terme « miner » viens de l’analogie avec les mines d’or, le minage c’est le fait de créer de la monnaie en trouvant le prochain bloc. Rien à voir avec la preuve de travail, qui est juste un mécanisme de consensus (qui peut être corrélé ou non avec le mécanisme de création monétaire).
S’il vous plaît n’utilisez pas le terme « miner » dans vos présentations sur Duniter/Ğ1, préférez le terme « forger ».
D11 : Un seul nœud trouvera le bon hash -> c’est faux. D’une part il n’y a pas le bon hash mais une plage de hashs valides. D’autre part, il y a bien des cas où plusieurs nœuds peuvent trouver un bon hash en même temps.
D12 : Vous parlez du cas du bitcoin sans le préciser explicitement. Plus globalement, vous mélangez trop ce qui relève du bitcoin de ce qui relève de Duniter/Ğ1, ce qui fait que même en suivant avec une parfaite concentration, la personne qui ne connaît pas Duniter/Ğ1 ne peut pas dissocier les deux.
Surtout qu’à la diapo suivante vous présentez du code spécifique à Duniter/Ğ1, ce qui laisse croire à tort que ce qui vient d’être dit dans la diapo d’avant concerne Duniter/Ğ1.
D13 : Incompréhension de ce qu’est le préfixe. Il aurait été préférable de poser la question ici avant, ou de ne pas parler du préfixe. Il ne sert pas du tout à gérer une éventuelle explosion de la difficulté. De plus, parler du préfixe dans une présentation de découverte de Duniter/Ğ1 n’a aucune plus-value, c’est un détail technique qui n’a à mon humble avis pas sa place dans une présentation ciblant un public qui ne connaît pas Duniter/Ğ1.
Le préfixe sert uniquement à éviter que plusieurs nœuds avec la même clé ne calculent les mêmes preuves, c’est présent uniquement pour permettre aux membres qui le souhaitent d’avoir leurs nœuds membres sur plusieurs machines. Même remarque pour nonceBeginning, un détail qui n’a pas sa place dans une présentation à un public découvrant Duniter/Ğ1.
D18 : il est faux de dire que la toile de confiance permet d’identifier les nœuds, elle permet d’identifier les membres, c’est très différent. Un membre peut avoir plusieurs nœuds et un nœud peut ne pas être membre (nœuds miroirs).
D19 : La façon de présenter laisse croire que la WoT a été mise en place pour mettre en place une difficulté personnalisée −> c’est faux c’est une conséquence heureuse de la WoT, mais sa raison d’être est uniquement de s’assurer que chaque être humain n’a qu’un seul compte membre afin qu’il ne crée qu’un seul DU par jours (symétrie spatiale).
D21: En fait si le tout dernier bloc compte, j’ai moi-même fait l’erreur, car la subtilité c’est de clarifier ou est l’observateur de cette fenêtre courante (à quelle étape), cf ce thread : Problème fenêtre courante dans Remuniter, Cesium et Silkaj
D27 : « un RPi3 trouve environ un bloc tous les trois jours et ce sera toujours comme ça » => c’est faux. On voit bien en observant les statistiques de pwMin que plus il y a de nœuds membres plus powMin augmente, donc une machine donnée trouvera de moins en moins de blocs. D’ailleurs à l’époque les RPi3 trouvaient en moyenne un bloc par jour
Si le nombre de membres calculant continue d’augmenter sans cesse, alors viendra un jour ou RPi ne trouveront qu’un bloc par mois, par ans, etc
D28 : la création monétaire journalière n’est pas « distribuée à parts égales », chaque membre cocréer sa part de monnaie, c’est une distinction sémantique très importante.
D29 : le « chapeau » sur le Ğ se nomme une brève : https://fr.wikipedia.org/wiki/Brève
D29: chaque membre « perçoit » un DU −> non, chaque membre créer un DU.
Césium 34’: « toucher » un DU -> « distribuer/percevoir/toucher », vous êtes, vraiment dans le domaine sémantique de la réception et pas de la création, ce qui a pour conséquence de faire rater le point essentiel de la Ğ1: le fait de devenir créateur de sa part de monnaie.
En conclusion, le plus gros tord de cette présentation est de n’avoir pas clairement séparé la partie concernant le bitcoin de la partie concernant Duniter/Ğ1, en passant de l’un à l’autre constamment cela embrouille et ne permet pas de distinguer ce qui relève du bitcoin de ce qui relève de Duniter/Ğ1.
Il aurait été préférable de faire une première partie dédié au bitcoin, en introduisant tous les concepts communs entre Duniter/Ğ1 et bitcoin mais sans parler de Duniter/Ğ1 (blockchain, Consensus, Proof-of-Work) puis dans une seconde partie de parler que de Duniter/Ğ1 et plus du tout du bitcoin (pour bien séparer ce qui relève de l’un ou de l’autre).
Un autre point qui manque, ce qui est embêtant vu que ça concerne l’axe central de cette présentation (pour d’autres types de présentation sur Duniter/Ğ1 ce manquement ne serait pas du tout gênant) : le fait de ne pas avoir dit que le motif de hash à obtenir n’est pas qu’un nombre de zéro mais qu’il y a une contrainte sur le dernier caractère du motif afin de gérer plus finement la difficulté que dans bitcoin.
D’ailleurs, le public averti remarquera le hic, une difficulté de 89 demande cinq zéros, et la fin on voit une difficulté de 91 qui demande aussi cinq zéros, donc la difficulté ne pose pas comme seul contrainte un nombre de zéros.
Le mail est bien un service utilisant un protocole de réseau centralisé, le serveur qui sert de référence est bien centralisé (serveur IMAP).
Il y a certes une copie en local des mails, mais ils sont récupéré de façon centralisé (on se connecte à point d’entrée en particulier pour synchroniser ses mails et non à un noeud d’un réseau d’ordinateur pair à pair).
Pour l’aspect distribué des blockchains, nous sommes d’accord et c’est bien ainsi que nous avons souhaité le présenter. Mais peut être n’avons nous pas été suffisamment clair à l’oral (cela dit c’est écrit noir sur blanc au slide 4)
Nous sommes d’accord. D’ailleurs le terme forgeur à été utilisé plus tard lors de la partie sur Duniter (slide 28).
Toutes les diapos de 1 à 18 (début) concernent la blockchain en général et effectivement Bitcoin est cité principalement comme exemple concernant la Proof-of-Work pour des raisons de popularité de ce dernier, mais n’est aucunement le sujet de la présentation. Nous sommes désolé si ce point n’a pas paru suffisamment clair.
Duniter est détaillé à partir du slide 19, même si les morceaux de code de Duniter sont utilisé sur la partie explication de la blockchain (slides 1 à 18 donc), mais ce sont des bouts de codes assez génériques qui certes sont issus de Duniter (et à l’oral il est bien précisé que ces exemples de codes sont issus de Duniter), mais sont une implémentation (comme une autre) de principes générales communs à la Proof-of-Work, et utilisé uniquement comme illustration de ces concepts.
Exact, c’est une erreur de confusion certainement lié au stress, il le sait très bien que c’est pas le protocole mais le code de l’implémentation dans Duniter
Ah oui, j’avais pas relevé cette erreur d’Adrien, pourtant je le sais puisque j’ai moi même plusieurs noeuds avec des préfixes différents Merci pour le rappel.
Effectivement nous pourrions simplement dire que c’est des spécificités de Duniter et dire que nous les détaillerons pas, puisque le plus important est d’expliquer le mécanisme d’incrémentation du nonce.
Je vais en parler avec Adrien, peut être pouvons nous ici éviter de mettre du code et juste expliquer le principe.
Exact, j’ai manqué de précision. Le fond du propos était de dire que Duniter se repose sur la WoT (et le préfixe que je n’ai pas precise (mais ça m’a semble un détail inutile pour la compréhension)) pour identifier un noeud membre pour lui appliquer la difficulté personnalisé.
Par la suite je précise que les membres de la toile de confiance peuvent calculer ou non et peuvent être membres sans même avoir de noeud.
Effectivement, mais comme c’était pas le sujet principale de la présentation, nous n’avons pas voulu insister sur les éléments liés à la monnaie libre particulièrement, seulement sur l’usage de la WoT dans le cadre de la difficulté personnalisée de Duniter.
Cela dit, effectivement pour de futures présentations, je note de bien préciser en introduction de la Toile de confiance, que ce n’est pas sa raison d’être, et de préciser cette raison d’être en fin de présentation sur la partie monnaie libre.
La méthode actuellement utilisée par Duniter est de regarder l’historique des X derniers blocs et considérer que le nombre de membres calculant c’est le nombre de membres ayant écrit au moins 1 bloc sur les X derniers blocs sans compter le tout dernier bloc.
Je pense qu’ici le diable se cache dans les détails, comme on dit, et que le mot “tout” dans “tout dernier bloc” signifie: sans compter le bloc HEAD (et non le bloc HEAD~1).
Si cette formulation n’est pas suffisamment claire, il faudrait donc également la corriger dans cette page Wiki. Peut être une formulation: “Sans compter le prochain bloc à valider” serait plus appropriée ?
Ok, en effet, merci c’est noté
Cela étant dit, un ajustement du facteur d’exclusion peut limiter cette effet, par exemple en ajustant le pourcentage de rotation (conf.percentRot) pour qu’une plus grande part du réseau soit exclue, et donc limiter le nombre de noeuds calculants.
Car d’un point de vue consommation énergétique, cela serait dommage que nous arrivions à un niveau de difficulté commune qui fasse qu’un RPi ne puisse valider qu’un bloc par mois ou pire par an, non ?
Dans la TRM on dit que c’est co-créé, mais dans l’implémentation technique actuelle, chaque membre ne co-créé pas (aucune action n’est faite par les membres eux même), c’est un bloc qui est forgé et enregistré dans la blockchain, donc c’est bien “distribué”.
Et comme c’était une présentation technique de Duniter, et non une présentation théorique de la TRM…
Donc même si sémantiquement, dans le cadre d’une présentation de la TRM, c’est très important en effet, techniquement dans Duniter c’est factuellement inexact de dire que c’est co-créé
Tout au plus, on peut dire “On dit que la monnaie est co-créée puisque chaque membre en a une part égale”, et ici le “on dit” est important, car cela permet de distinguer la réalité technique, du concept théorique de co-création issu de la TRM.
Je note donc de préciser cet élément, sous cette forme, pour les prochaines présentations techniques.
C’est pourtant comme cela que nous l’avons conçue, toute la première partie est générique et non spécifique à Duniter, Bitcoin ou autres (slides 1 à 18 (début)), et la deuxième partie spécifique à Duniter.
D’ailleurs la première partie ne concerne aucunement Bitcoin, mais la blockchain et la preuve de travail (Proof-of-work) de manière générale. Nous citons Bitcoin simplement comme un exemple d’implémentation d’une blockchain avec consensus par Preuve de travail, car c’est le plus connu, mais cette première partie n’est aucunement une présentation de Bitcoin.
C’est d’ailleurs parce que cette première partie (slides 1 à 18 (début)) n’est pas une présentation de Bitcoin, mais de concepts généraux à la blockchain et à la preuve de travail, que nous nous sommes permis d’utiliser du code de Duniter comme exemple d’implémentation de ces concepts de bases, puisque Duniter les implémente également.
Dans toute cette première partie, que cela soit Bitcoin, Ethereum ou Duniter, ils ne sont cités que comme exemples et illustrations des concepts présentés, et non comme sujets.
Le fait que tu insistes particulièrement sur ce point démontre que nous n’avons pas été assez clair sur le fait que ce ne sont que des exemples.
Nous tacherons d’être plus clair lors des prochaines présentations sur ce point.
Merci pour cette précision As tu un lien/document détaillant, ou peux tu détailler ici, le principe de fonctionnement de cette contrainte pour qu’on puisse détailler cet aspect dans de futures présentations techniques ?
Tout dépend a quel niveau tu découpe les différents types de réseaux. Pour moi il y a une différence entre la messgerie fb et le mail par exemple. Le 1er est centralisé et le 2ème décentralisé.
J’emploie ici le terme “décentralisé” dans le sens de plusieurs centres, et non pas dans le sens “distribué” / “acentré” (qui est souvent nommé décentralisé par abus de langage).
Le mail est tout autant décentralisé que Mastodon ou Diaspora* par exemple. Au lieu de choisir ton pod tu choisi ton fournisseur de mail, mais tu peut communiquer avec ceux qui sont chez un fournisseur différent, donc c’est bien décentralisé. Si tu nomme cela “centralisé” alors dans ce cas Mastodon, Diaspora*, les CHATONS, … sont centralisés, ça n’a pas de sens.
Alors pourquoi la slide 3 les fait apparaître sous “réseaux décentralisés” ?
Le problème c’est que vous faites références maintes fois a Duniter et a Bitcoin en même temps pendant la première partie censée être générique/abstraite, du coup votre plan ne se voit pas du tout.
Quitte a faire une partie générale sur la blockchain et la PoW autant la faire vraiment abstraite en ne citant aucun exemple, puis faire une partie distincte pour chaque exemple
Arf merci, c’est une erreur de ma part dans cet article, je vais la corrigée
Le problème est justement que l’on ne peut pas trop diminuer percentRoot sinon un s’expose a des risques de blocage complet du réseau, certains noeuds de la fenêtre courante sont en réalités éteints et désynchro. Et en cas de fork on divise par 2 les noeuds sur chaque branche mais en gardant la même fenetre courante, du coup avec une valeur trop élevée de percentRoot on peut se retrouver dans une situation de blocage ou aucune branche ne peut avancée.
Enfin, un percentRoot trop élevé augmente la surface d’attaque. Supposons qu’il y ai une proportion P de noeuds membres malhonnêtes et complices qui souhaitent prendre le contrôle de la monnaie. Alors ils peuvent tous trouver au moins 1 bloc pour rentrer dans la FT puis cesser de calculer pour rester en bas de la FT, jusqu’à ce qu’aucun d’eux ne soit dans la part exclue, a ce moment la, si P deviens significatif devant (1-percentRoot) ils peuvent prendre le contrôle de la monnaie.
Pour le coup je pense que c’est un mauvais choix de présenter ainsi. Pour faire une bonne présentation, toujours partir du principe que le public entend mal, vois mal, et n’est pas parfaitement concentré en permanence. Du coup, il faut que même avec des brides on ne mélange pas les choses.
Citer plusieurs exemples différents en simultanés comme vous l’avez fait perdra même un public très averti (en tout cas moi çà m’a perdu).
Je vous invite a vraiment séparer les parties, a ne pas citer des exemples différents dans une même partie
C’est déjà détaille dans le wiki :
Comment s’applique la difficulté
La valeur numérique de la difficulté correspond directement à une plage d’empreintes possibles parmi toutes les empreintes possibles. Dans Duniter l’empreinte d’un bloc c’est le hash hexadécimal sha256 du bloc. Ce qui veut dire que chaque caractère de l’empreinte n’a que 16 valeurs possibles : les chiffres de 0 à 9 et les lettres de A à F.
Pour interpréter une difficulté il faut effectuer la division euclidienne de cette difficulté par 16. Exemple avec 70 :
70 // 16 = 4 reste 6 . Donc les empreintes valides sont celles qui commencent par 4 zéros et dont le 5ème caractère est inférieur ou égal à 9 (car on commence à F (index 0), puis on descend … E(1), D(2), C(3), B(4), A(5), 9(6) ). On écrit alors que les empreintes valides commencent par : 0000[0-9]
Parce que la blockchain c’est un réseau décentralisé ET distribué
Dans les réseaux décentralisés, il y a ceux qui ne sont pas distribués (i.e: chaque noeud ne se synchronise pas avec les autres), tel que Bittorent ou Émule, et ceux qui sont distribués (Blockchain par exemple).
Cela étant dit un réseau centralisé peut aussi être distribué, exemple: Clusters de serveurs Web ou de BDD avec réplication.
Je perçois donc les soucis de précision ici. Il faut bien qu’on précise oralement qu’un réseau distribué peut être centralisé comme décentralisé, et que la blockchain est un réseau décentralisé ET distribué.
Et merci aussi pour les infos sur l’application de la difficulté. Je vais ajouter une diapo là dessus sur la partie Duniter
Ça dépend de la définition de chacun derrière le terme “décentralisé” en fait. Pour moi un réseau de serveurs blockchain n’est pas “décentralisé” mais il est “pair à pair” c’est tout a fait différent.
Le terme “distribué” n’est pas adapté, il ne devrait pas être utilisée en réseaux, lire ceci a ce sujet : https://www.goffi.org/post/2015/11/10/centralisé,-décentralisé,-P2P,-mais-c-est-quoi-tout-ça
Oui tout dépend de la définition en effet. Cela étant dit les réseaux pair à pair et les blockchains sont communément cités comme exemples de réseaux décentralisés (et distribués pour les blockchains), que cela soit dans les présentations techniques ou les formations que j’ai pu suivre.
Mais je conviens que ton point de vue se défend tout à fait et est cohérent.
Quoiqu’il arrive il me semble important de pouvoir s’assurer que le nombre de noeuds membres calculants ne puissent pas être fortement élevé, pour pouvoir limiter la consommation énergétique.
Si conf.percentRot semble effectivement pas la bonne variable d’ajustement pour ce cas de figure, est-ce que que réduire la valeur de conf.powMaxHandicap (utilisée pour exclure effectivement les noeuds ayant une difficulté personnalisée supérieure à current.powMin + conf.powMaxHandicap) peut être une solution à cette problématique ? Ou est-ce que cela risquerait aussi des situations de blocages ou de prises de contrôle trop importantes ?
D’une manière générale, est-ce qu’il y a déjà des pistes qui ont été envisagées pour gérer cette problématique de potentielle montée significative de la consommation énergétique si le nombre de noeuds venait à être très élevé au point qu’un RPi ne valide plus qu’un bloc par mois, voir pire, par an?
C’est un éternel débat, le problème en limitant les membres calculant d’une façon ou d’une autre c’est qu’on cours le risque de ne limiter que les membres honnêtes et donc d’avoir une proportion de membres malveillants non négligeable face aux membres honnêtes
Si on veut absolument se fixer la limitation de la consommation énergétique comme objectif (ce qui n’est pas forcément une évidence), alors je pense que l’on devrait plutôt se concentrer sur la création d’un autre mécanisme de consensus afin de ne plus avoir de preuve de travail
Il y a déjà eu plusieurs pistes proposées a ce sujet, j’ai bon espoir qu’on arrive a se débarrasser de la PoW a long terme.
En attendant ils y a déjà d’autres pistes pour atténuer la conso de notre PoW qui ont été proposées et qui sont prévues pour l’avenir du protocole :
Changer le calcul du handicap pour l’augmenter (remplacer la médiane par le 2ème tiercile).
Mettre en place un bonus aléatoire pour les membres les plus bas dans la fenetre courante.
En fait, pour moi la 1ère partie censée être “générique” ne vas pas car elle énonce plusieurs choses qui sont fausses dans le cas de Duniter/G1 (registre de transactions, PoW par nombre de zéros, etc).
Je pense qu’il serait beaucoup plus pertinent et plus clair de revoir le plan ainsi :
Partie 1 : le bitcoin : la blockchain, le registre, la PoW, etc
Partie 2 : DUBP: les spécificités de notre protocole
Ou alors, si vous tenez absolument a garder une partie abstraire sur la blockchain et les mécanismes de consensus alors il faut adapter pour rester vrai pour tout type de blockchain :
Remplacer “transactions” par “événements” (D5 et 8), une blockchain est un registre d’événements, ce n’est pas forcément des transactions. Vous pouvez citez plusieurs exemples d’événements : transactions actes notariaux, etc
Remplacer nombre de zéros par “doit commencer par un certain motif”, ce motif pouvant être un nombre de zéros ou tout autre chose.
Mes autres retours :
D5 : ce serait bien de faire apparaître le hash du bloc précédent dans chaque bloc, ça permettrait de comprendre visuellement comment les blocs sont liés
D9 : Je ne suis pas sût qu’il soit valide de parler d’arbres de merkel, une suite de blocs chaînée ne me semble pas être un arbre de merkel, un arbre de merkel c’est quand on a des feuilles qui contiennent des datas et des noeuds qui contiennent les hashs des hashs de leurs feuilles. Or un bloc d’une blockchain n’est ni feuille ni noeud, du coup je ne doute de la pertinence de se rapprochement.
D12: remplacer par “hash a trouvé doit commencer par un certain motif”, avec 2 exemples différents de motifs pour ne pas laisser croire que le motif serait forcément un nombre de zéros.
D20 et D22: il me semblerait plus pertinent de prendre un exemple les spec du protocole ou se qui est sur le wiki ou d’écrire un méta-algo simplifié. C’est le protocole DUBP qui fait foi, pas l’implémentation Duniter, dont le code peut être refactoré tout autrement.
D24: il peut être bien de dire pourquoi le log, extrait du wiki :
on prend le logarithme népérien de ce rapport pour éviter que le handicap devienne excluant lorsque la fenêtre courante devient très grande, c’est ce qui fait la subtilité du handicap, son rôle n’est pas d’exclure mais de niveler la difficulté de chacun en fonction de sa puissance pour que tout le monde ait a peu près les mêmes chances de calculer.
Autre remarque pas liée a une diapo particulière : ce serait bien de distinguer le protocole DUBP de son implémentation historique qu’est Duniter
