Ayant maintenant un serveur duniter qui tourne, j’essaye de comprendre la difficulté personnalisée. J’ai lu https://duniter.org/fr/wiki/duniter/preuve-de-travail/ et j’ai l’impression que quoi qu’il en soit, il existe une difficulté minimale, la difficulté commune, qui assure qu’il y aura des blocs régulièrement calculés (tous les avgGenTime).
Ma question est la suivante : est-ce que cela sert à quelque chose de faire tourner un serveur donc la puissance ne lui permet pas de calculer un bloc en avgGenTime avec la difficulté minimale ? Sauf coup de bol, ce serveur va passer son temps à se faire doubler, et les serveur qui vont effectivement calculer la monnaie sont ceux qui sont suffisamment puissants pour aller plus vite que la difficulté minimale.
J’ai l’impression que c’est empiriquement ce qui se passe, en regardant qui a calculé les derniers blocs. J’ai l’impression que l’on voit les même personnes tourner par séries de 10 à 15 blocs, avec rarement une autre personne trouvant un bloc.
Ne pourrait-on pas envisager un ajustement de difficulté personnalisée allant sous la difficulté minimale, pour que les petites machines puissent aussi participer ?
Comme tu as pu le lire dans ce lien du Wiki, tu as deux concepts clés sur lesquels on peut jouer :
facteur d’exclusion
handicap
La difficulté commune est en effet présente pour s’assurer qu’on ait au moins 1 bloc toutes les 5 minutes en moyenne.
Dès lors que ton nœud calcule un bloc il subit alors le facteur d’exclusion pendant un certain nombres de blocs : pour des raisons d’efficacité, ton nœud ne va plus essayer de calculer le prochain bloc durant cette période (je ne sais pas si tu l’avais noté). La réussite étant trop improbable.
Ensuite, ton nœud peut avoir réussi à calculer plusieurs blocs dans la « fenêtre courante ». Dans ce cas, si tu dépasses la médiane du nombre de réussites dans cette fenêtre, un handicap s’applique, fonction de ton niveau de dépassement de la médiane.
Or, le niveau de la médiane dépend … du nombre de nœuds calculant. Plus il y a d’auteurs (même avec 1 seul bloc dans la fenêtre courante), plus la médiane tend à baisser, et donc plus le travail devient difficile pour les auteurs les plus prolixes.
D’où l’idée de maximiser le nombre de nœuds, d’inciter à installer son petit Raspberry PI derrière un pot de fleur.
edit : tu peux voir le nombre de blocs par auteur dans la fenêtre courante sur Remuniter : https://remuniter.cgeek.fr, dans la colonne de droite. Tu peux calculer la médiane par le même coup. D’ailleurs on voit bien où se situe le handicap, il est noté. (merci @elois)
edit 2 : j’ai oublié de répondre à ta question :
Je ne sais pas trop, je ne voudrais pas non plus favoriser des attaquants qui profiteraient de ce “bonus” pour parasiter la chaîne en calculant des blocs vides de temps à autres.
Oui, je l’avais lu. Mais il faut que le facteur d’exclusion soit suffisamment important pour laisser une chance à tout le monde de calculer un bloc. Donc si on est 30 à calculer, il faut que cela soit au moins 30 blocs. Si cela dépasse le temps moyen souhaité, cela fait baisser la difficulté commune, et cela donne une chance aux machines sans handicap. Quand je regarde https://g1.duniter.fr/#/app/network je vois par exemple que @florck calcule un bloc tous les 10 blocs. Toi c’est un peu plus souvent. Et pareil pour en tout une dizaine de personnes.
Je n’arrive pas à accéder à remuniter, et je suis curieux de voir si je suis dans la fenêtre courante (j’ai trouvé un bloc ce matin à 10h35). Tout nœud qui sort de la fenêtre courante parce que la difficulté commune est trop importante diminue le handicap pour les nœuds dans la fenêtre, qui vont donc trouver des blocs plus vite et augmenter la difficulté commune. D’où ma nouvelle question : est-ce que la fenêtre courante est assez grande ?
Il est sous ma connexion Internet personnelle, ça peut prendre 1 minute à charger la 1ère fois.
Le facteur d’exclusion minimum est de 2, c’est à dire qu’il double le niveau de difficulté : par exemple si l’on a une difficulté commune de 80 (= 5 zéros), alors la difficulté de celui subissant un facteur d’exclusion de 2 aura une difficulté de 160 (= 10 zéros). Ce qui est (16^(80/16) - 1) = 1.048.575 de fois plus difficile que la difficulté 80 seule. On considère donc qu’un auteur subissant ce facteur comme étant exclu de la preuve. Dans la Ğ1, ça correspond à 1/3 des calculateurs de la fenêtre courante (c’est un paramètre de la monnaie).
Qui serait donc le 31ème permettant de débloquer la situation, si l’on est que 30 ? Il faut que l’exclusion dure moins que 1 bloc par calculateur. Nous on a mis 30%. Donc 10 blocs d’exclusion ici.
C’est tout à fait vrai. C’est même un problème
Sa taille vaut 5 fois le nombre de calculateurs, plus 1. Donc si l’on est 19 calculateurs, sa taille vaut 96 blocs.
D’où sort ce 5 ? De nulle part. Quoi que la valeur 0 aurait signifié aucune fenêtre, la valeur 1 exacerbe la sortie rapide des petits nœuds, …
Donc je te répondrais : je ne sais pas. Mais une valeur trop grande va également donner un grand poids aux nœuds allumés épisodiquement, par exemple. Alors je ne sais pas trop quelle valeur prendre.
Cela explique bien ce que j’observe : 30% de 20 calculant, c’est environ 7, donc cela veut dire qu’un groupe de 8 à 10 membres tournent pour calculer des blocs. C’est ce que l’on observe sur la fenêtre courante : les 5 premiers ont calculé 50% des blocs. Si on monte au 8 premiers, on arrive aux 2/3 des blocs.
Je pense que 30% est petit. Mais surtout je pense que le handicap est beaucoup trop faible : @Benoit_Lavenier a trouvé 10 blocs, il a une difficulté de 91. En bas du tableau, ceux qui ont trouvé 1 bloc il y a longtemps ont une difficulté de 86 (j’ai écris ceci pendant la maintenance… depuis Benoit a trouvé d’autres blocs). Je n’ai pas l’impression que le handicap compense cette différence. (Merci beaucoup pour remuniter, ça explique super bien la difficulté.)
Mais bon, la solution est peut-être une proof of stake… mais c’est pour dans longtemps. Je vais laisser tourner mon odroid quelques jours, pour voir si cela s’équilibre, mais pour le moment je n’y crois pas.
On a déjà tenté un percentRoot plus faible et c’était trop bloquant en cas de fork, on ne peut pas exclure une part trop importante des calculateurs au risque de retrouver le réseau paralysé, on l’a constaté sur une monnaie de test on l’on excluai 50% des calculateurs (contre 33% aujourd’hui).
On pourrait effectivement augmenter la valeur du handicap mais attention a ce qu’il ne devienne pas excluant pour un grand nombre de calculateurs sinon le réseau se retrouvera bloqué quasiment a chaque fork…
Alors pas une PoS ce serait contraire aux libertés économiques mais en revanche j’ai proposé une alternative qui nous permettrai peut être de nous passer de la PoW et que je t’invite a lire : Abandonner la preuve de travail grâce à la toile de confiance?
Je n’ai effectivement pas réfléchi au problème des forks, c’est compliqué en effet.
J’avais lu la discussion pointée, c’est un peu ce que j’entends par proof of stake (pas dans le sens combien de monnaie on a, comme dans Tezos, mais dans le simple fait d’être membre). Je comprends bien que mettre au point un tel algo est très compliqué (une fois de plus pour les forks), mais cela me paraît être dans l’esprit de ne pas chercher à utiliser la puissance de calcul comme facteur discriminant.
Une information qui pourrait faire avancer la discussion est celle-ci : avez-vous une estimation du hash-rate minimal nécessaire pour participer à la blockchain ? À l’extrême, si on ne calcule pas un hash toute les 5 minutes, c’est clair qu’on ne peut pas participer. Il y a donc un minimum. Ce serait intéressant de quantifier, en fonction de la distribution de hash-rate des autres acteurs, quel hash-rate minimum est nécessaire pour rester dans la fenêtre courante.
La notion de hash-rate est ici à prendre avec des pincettes, car dans Duniter la preuve est en fait composée d’une signature puis d’une fonction de hashage de ce qui a été signé et de la signature apposée.
Néanmoins le raisonnement reste possible.
Je n’ai pas d’estimation de hash-rate à donner par contre.
En tout cas, toi comme @SimonLefort avez un bloc dans la fenêtre de fork actuellement.
Après le but n’est pas d’obtenir une égalité, mais au moins une part non nulle d’écriture dans la fenêtre de fork dans l’hypothèse d’un réseau majoritairement composé de machines type PC ou petit boitier ARM…
Mais je ne souhaitais pas non plus qu’un Raspberry PI poussé à 10% de CPU soit suffisant pour faire jeu égal avec d’autres nœud 8 cœurs à 100% de CPU.
Car la preuve de travail reste le mécanisme central de synchronisation entre les nœuds concernant la blockchain Duniter, c’est ce mécanisme qui permet de dire “ceci est le nouveau bloc” pour le réseau entier. Et donc “voici une transaction officialisée, ainsi que celle-ci et cette autre-ci, nous avons également une identité, ses 5 certifications, etc”.
Or, manifestement un Raspberry PI à 10% de CPU ne calcule pas sa preuve aussi rapidement qu’un Core i7 à 100%. Même si c’est possible étant donné le caractère aléatoire de la preuve, en moyenne le Core i7 trouvera largement plus de preuves que le Raspberry.
Il y a actuellement d’autres idées pour abandonner totalement la preuve de travail (Proof-of-Stake, Holochain, Stellar, …). Mais disons que pour démarrer une monnaie libre P2P début 2017, la preuve de travail était un mécanisme simple et rapidement implémentable, ayant fait ses preuves.
Maintenant il est possible de suivre d’autres voies, surtout étant donné l’incommensurable avantage de Duniter de posséder une toile de confiance. Je peux te donner celles déjà évoquées ici :
Mon RPi3 a trouvé 3 blocs sur la nuit, oh joie! Perso, si je sais que ça aide un peu le réseau, que ça renforce la sécurité, etc., je me fous pas mal de savoir combien de nœuds je peux bien calculer.
Par contre, je trouverais ça dommage de finir tourner une machine pour rien, si je ne calculais jamais aucun nœud.
Calculer des blocs n’est pas le seul but d’un noeud membre : il y a aussi le vote en cas de fork qui est important, c’est ce mécanisme qui empêche que le réseau soit contrôlé par une seule machine (ou un petit groupe de machines)
Je suis rassuré de voir que mon odroid (a priori moins puissant qu’un raspberry 3, mais avec plus de RAM) a réussi a trouver 5 blocs en 24h. À part ressortir mon RPi 1 du placard, je n’ai pas de machine moins puissante.
Je suis d’accord avec l’approche pragmatique suivie pour la ğ1. J’aime bien comprendre les choses en proposant des alternatives et avoir des explications sur pourquoi j’ai tort. Merci beaucoup de vous prêter à mon jeu
