Block issuance distribution

This is what it is looking like today, approx. 22 hours after 0.40 started to be used:

I bet this will be even more homogeneous in few days.

This diagrams represents the last 115 blocks of TestNet. A full day is made up of 288 blocks (60’ x 24 / 5’ = 288), so the data only reflects the new usage in a limited period of time, excluding the issuers of the last 24H which were still using v0.3 protocol at that time.

4 Likes

It’s already a spectacular result :clap:

1 Like

Very good indeed. :thumbsup:

With a mix of old 0.3 (oups…) and new protocol 0.4 distribution:

There is 4,5 issuers which generate 50% of blocks, like on ktorn chart.

File: duniter_5000_blocks_repartition.ods (9,0 Ko)

Data retrieved thanks to silkaj:

Issuers for last 5000 blocks from block n°43446 to block n°48445 from 24 issuers
|   percent | uid        |   blocks |
|-----------+------------+----------|
|      13.1 | pafzedog   |      657 |
|      11.8 | gnu-tux    |      592 |
|      11.3 | nay4       |      563 |
|       8.4 | cgeek      |      418 |
|       7.4 | ktorn      |      368 |
|       7.2 | vincentux  |      360 |
|       6.0 | moul       |      298 |
|       5.1 | mmpio      |      255 |
|       4.8 | kimamila   |      242 |
|       4.2 | modulix    |      208 |
|       4.0 | Jean-F     |      198 |
|       3.3 | gege53     |      165 |
|       3.2 | urodelus   |      158 |
|       3.0 | inso       |      152 |
|       2.5 | hacky      |      123 |
|       1.1 | squeeekgps |       56 |
|       0.9 | Tortue     |       43 |
|       0.8 | RavanH     |       40 |
|       0.8 | Galuel     |       40 |
|       0.6 | elois      |       32 |
|       0.3 | filb       |       16 |
|       0.2 | idyllei    |        9 |
|       0.1 | ciryll     |        5 |
|       0.0 | Matteo     |        2 |
2 Likes

Hello,
Vous pensez quoi de cette nouvelle formule de la POW?

Je ne sais pas s’il faut attendre encore que les plus gros calculateurs voient leurs complexités augmentées.
Mais avec le peu de temps que cette nouvelle formule a été mise en place, on peut observer que la complexité générale de la blockchain a augmenté, et que le partage du minage des block est bien moins équitable que précédemment.

J’ai sorti les données en graphe sur la fenêtre courante ce matin :

C’est en effet clairement moins équitablement réparti que dans la précédente version.

J’ai déjà réfléchi à cette observation ce week-end, et j’ai été tenté de modifier la formule pour que le handicap soit exponentiel de la façon suivante :

Rappel de la formule DUP 0.5 :

PERSONAL_DIFF = PoWMin + PERSONAL_HANDICAP

Sachant que PERSONAL_HANDICAP > 0 dès lors que l’on dépasse la médiane de nombre de blocs émis par membre dans la fenêtre courante. Ainsi l’on a, pour une médiane à 6 blocs :

  • un handicap de 0 pour le prochain bloc si l’on a émis 5 blocs
  • un handicap de 1 pour le prochain bloc si l’on a émis 6 blocs (+19% de difficulté)
  • un handicap de 2 pour le prochain bloc si l’on a émis 7 blocs (+41%)
  • etc.

J’ai donc été tenté, pour un hypothétique DUP 0.6, de faire :

PERSONAL_DIFF = PoWMin + FLOOR(EXP(PERSONAL_HANDICAP))

Ce qui aurait donné :

  • un handicap de 0 pour le prochain bloc si l’on a émis 5 blocs
  • un handicap de 2 pour le prochain bloc si l’on a émis 6 blocs (+41% de difficulté)
  • un handicap de 7 pour le prochain bloc si l’on a émis 7 blocs (+235%, ça gratte un peu)
  • un handicap de 20 pour le prochain bloc si l’on a émis 8 blocs (+3088%, ça commence à piquer)
  • un handicap de 54 pour le prochain bloc si l’on a émis 9 blocs (+1 147 578%, c’est punitif)
  • etc.

Alors, comme ça, on se dit « chouette, ça roxxe, c’est plus équitable ». Oui mais ce n’est pas sans conséquence : on en revient plus ou moins à la situation DUP 0.4, où une partie des calculateurs est purement et simplement exclue du calcul au bout de quelques blocs émis au-dessus de la médiane. Ce n’était pas le but recherché avec la 0.5.

Après, je dois dire que ça ne me gêne pas d’implémenter cette logique, si vous jugez que cela est préférable à la 0.5 actuelle. Au final, DUP 0.5 et 0.6 auront simplement lissé le comportement de la 0.4, qui était infiniment plus punitive : dès que l’on calculait un bloc, on se voyait exclu du calcul tant que suffisamment d’autres membres n’avaient pas eux-mêmes calculé de blocs.

A noter quand même que la situation actuelle est toujours un rapport de puissance personnelle sur la puissance totale, et donc plus le nombre de participants augmente, plus cet écart est faible.

C’est comme vous le souhaitez.

1 Like

Personnellement, j’apprécie le fait que l’on ne soit pas obligé d’avoir une machine de guerre pour miner des block.
j’apprécie également que ce soit le plus équitable possible entre les membres.
Maintenant je comprends qu’avoir des noeuds exclus du calcul de la POW peut poser des problèmes en cas de fork, ou l’une des branches est dans l’impossibilité de miner d’autre block car la plupart des nœuds sont exclus.
Mais ce problème sera-t-il toujours présent quand plus de nœuds seront dans le réseau?

Autre sujet (mais lié):
Pour moi il faut garder en tête l’impossibilité de calculer plus de 5 blocs consécutifs par un même membre.
Mais que ce passe-t-il si plusieurs membres (qui n’ont que la POW min car jamais miner de block ) se mettent d’accord pour calculer (par un super calculateur) des blocs consécutifs afin de supprimer un précédent transfert de la chaine?

Pour cela, ils doivent donner leur clé privée au super calculateur. Ce qui fait qu’ils prennent le risque de perdre le contrôle total sur leur identité, leur compte en monnaie, et la production du DU.

Nul doute que cela se produira ne serait-ce que par extorsion du trousseau (via piratage par ex.), ce qui donne beaucoup de pouvoir à ce calculateur, c’est vrai. Mais ce potentiel de calcul est à mettre en balance avec la puissance totale du réseau, et donc plus y a de nœuds, plus ce pouvoir est dilué.

Maintenant, c’est aussi pour ce problème de “partage” de clé à un super calculateur que j’avais mis en place le mécanisme de rotation initial, jusqu’à DUP 0.4. Si l’on constate qu’il valait mieux le reprendre, on pourra toujours le faire. Mais plus ça traîne, plus ce sera difficile !

Je pense qu’exclure jusqu’à 1/3 du réseau est raisonnable. En général, dans les systèmes en haute-dispo, on considère que le quorum votant peut fonctionner tant qu’il reste 2/3 des nodes up. Donc ça me parait être correct. En dessous, on prend le risque que le quorum se bloque ou se split.

avec une complexité personnalisée, ce n’est (presque) plus la “puissance totale du réseau”, mais bien le “nombre total de noeuds” qui permet de dilué ce pouvoir.

Qu’entends-tu par “le mécanisme de rotation initial”?
le faite qu’un membre est vite exclu dès qu’il a miné un bloc ?
Si c’est le cas, c’est ce que j’étais en train de décrire précédemment:

  • Rien n’empêche à un super calculateur de miner dans son coin un premier bloc avec la clef privée d’un premier membre piraté, puis un 2eme bloc avec la clef d’un autre membre piraté, et ainsi de suite. Afin de garder une complexité de calcul la plus faible possible. Puis de publier la nouvelle chaine d’un coup.

Oui, mais exclu immédiatement, en fait.

Oui mais cette exclusion continue tant qu’1/3 de tous les membres calculant n’ont pas écrit eux-même un bloc. Donc sauf à avoir 1/3 des clés des membres calculant, la nuisance du super calculateur n’est que partielle.

Ha bien vu :wink:
il me manquait cette info

Alors je vote haut la main pour la version 0.4 !

Dans la version 0.4, quelqu’un qui a calculé est exclu jusqu’à ce qu’1/3 des membres ait calculé un bloc ? Ca me parait énorme…

Une des raisons pour laquelle on est partie vers DUP 0.5 été le fait que dans le cas du réseau actuel de Test-net, avec une vingtaine de nœud membres, en cas de deux fork symétriques, les deux fork étaient bloqués étant donné qu’il arrivait qu’un nœud se retrouve tous seul a faire avancer la branche.
Ce 2/3 d’exclus n’était pas adapté aux forks avec cette taille de réseau monétaire.
Lors d’un fork, 2/3 de la branche principale se transforme en 2/3 sur chaque branche.
identités exclus / nombre d’identités qui calculent.
Sur une branche, le nombre d’identités exclus ne change pas mais le nombre d’identités qui calculent est celui du nombre total des deux branches.

Finalement, je commence à être convaincu que ça n’est pas possible qu’il y ait une équité entre des identités ayant un gros CPU et d’autres ayant un faible CPU. En même temps ça serait dommage pour ceux qui mettent a disposition une forte puissance de calcul de se retrouver à calculer le même nombre de nœuds que les autres.
Je pense pas qu’on revient à 0.4, car la fenêtre s’adapte mieux en cas de fork ? Pas sûr au final. Je vois pas comment gérer ce cas.
Dans le cas de 0.5, la fenêtre est plus grande et exclus plus difficilement en cas de fork. Avec cette proposition de 0.6, ça risque, en effet, de ressembler à 0.4.

Au final avec 0.5, la difficulté du réseau a beaucoup augmentée.

(Désolé, ce que j’ai écrit est très brouillon. Mais les idés sont là ! :slight_smile:)

Est-il possible de n’exclure qu’1/3 des noeuds tout en améliorant la distribution des blocs ? (cf mon commentaire plus haut, dans les réseaux distribués, il faut tenter d’avoir toujours 2/3 du réseau qui peut travailler…)

edit : ma réponse était pour @inso, mais avec le déplacement de sujet, ça indique que c’est pour Moul.

1/3 des membres qui calculent, c’est-à-dire ceux qui ont émis un bloc dans la fenêtre courante.

Ça paraît beaucoup, mais ça veut aussi dire que les 2/3 restant calculent en permanence. A quelques variations prêt bien sûr, il y en a qui arrêtent et d’autres qui se mettent à participer.

Mais pour résumer, on a 2 visions :

  • une qui consiste à dire que n’importe quel participant devrait avoir la capacité de poursuivre la blockchain tout seul s’il le souhaite (1)
  • une qui consiste à dire que ce bien est commun et qu’on ne peut pas en prendre le contrôle soi-même, mais que des semblables sont nécessaire à la poursuite de l’aventure (2)

A noter que 1) est en réalité toujours possible, on peut forker la blockchain quand on veut par exemple pour changer la difficulté et faire passer une blockchain du mode 2) vers 1).

J’étais parti pour 2) jusqu’à la 0.4, j’ai voulu tenter 1) depuis la 0.5.

edit 2 : mais en effet, le problème majeur que l’on avait c’était les forks, mais ces forks ont aussi leurs raisons : notamment parce que je propageais la nouvelle version du protocole de façon instantanée et non coordonnée, contrairement à la 0.5 qui a été planifiée, où il n’y a eu aucun fork majeur.

Si l’on sait éviter les forks majeurs, alors il n’y a pas vraiment de problème à avoir un algo à la 0.4.

2 Likes

en fait je ne comprends pas :innocent:
Pour moi cela ne corrige pas le problème, imaginons un vol de 6 identités membres (clef privée/publique) qui n’ont jamais minée (=> pow min et non exclu) il est alors possible de miner 6 blocs consécutifs grâce à chacune de ces 6 identités.

Avec le system de POW personnalisé (ou exclue) cela réduit drastiquement la complexité moyenne de la blockchain et permet de créer une nouvelle version de la blockchain bien plus facilement.

plus j’y réfléchis, plus j’ai peur de la POW personnalisé.

Oui, mais ça ne dure que 6 blocs. Sur 200 nœuds calculant, c’est 3% du temps qu’ils peuvent monopoliser. Et encore, cela suppose que le super calculateur soit largement plus puissant que les 194 nœuds restants, cela a un coût non négligeable pour une gêne assez infime, tout en sachant que la fonction de hashage reste aléatoire.

Par ailleurs, rien ne nous empêche, nous non plus, de calculer des blocs vides ou des blocs qui ne contiennent que des données qui nous intéressent personnellement. Nous avons alors un comportement similaire au super calculateur, sans avoir sa capacité de calcul. Si tout le monde agit en ce sens, la monnaie fonctionnera tout aussi mal, voire très mal.

Au final donc, ce n’est pas tant le super calculateur le problème (sauf en 0.5, là oui c’en est un) que la volonté des membres de sécuriser sa monnaie en démultipliant le nombre de nœuds pour la faire fonctionner.

C’est une fausse peur, car quand tu regardes Bitcoin ou les altcoins à base de PoW, là c’est clairement la voie royale pour avoir un contrôle centralisé. D’ailleurs c’est déjà le cas, il y a des “pools”. Et l’inquiétude grandit chaque jour, car l’intérêt pour le minage baisse (moins de coins à miner) ce qui va à terme signifie la mort de la monnaie (voir le cas de Auroracoin qui est mort justement par manque de puissance de calcul faisant balance à un attaquant).

D’ailleurs Bitcoin peut dores et déjà être tué : il suffit de voir qu’il y une puissance globale au réseau et que celui qui le veut peut investir un gros paquet de blé dans un super-calculateur et s’amuser à créer des blocs vides. Et avec les banques qui peuvent créer de la monnaie à volonté, c’est tout à fait faisable. Bitcoin est laissé vivant, il faut bien en avoir conscience.

Alors que dans un système qui réduit les possibilités d’écritures à des membres identifiés, avec un algorithme s’assurant d’une certaine rotation, là ça pose beaucoup plus de difficultés.

A mon humble avis.

1 Like

Je ne parle pas d’un déni de service, qui lui reste effectivement tout à fait limité (et peu d’intérêt a mon sens, sauf peut être pour les banques en place) mais je parle plus dans le cas d’une place de marché qui échange la monnaie libre contre d’autres monnaies. Où le but de l’attaquant est de supprimer de la blockchain le transfert de monnaie envoyé à la place de marché qu’il a effectué précédemment. (possibilité de dépensé plusieurs fois la monnaie de l’attaquant)

un ti exemple ici:
http://www.gldcoin.com/documents/GoldCoin_0.7_51percent_defense_october_11_2013.pdf

Ah oui, mais non, pour plusieurs raisons :

  • déjà le principe des crypto-monnaies des 6 blocs d’assurance du transfert : on considère un bloc comme entériné à partir de 6 autres blocs au-dessus. Si dans Duniter c’est plus, hé bien il suffira de dire que c’est plutôt 8, 15 ou 30. C’est moins bon que dans Bitcoin, mais ce n’est pas le plus important.
  • dans Duniter, pour que le réseau suive un fork, il faut 6 blocs au-dessus de la branche actuelle, donc là il faudrait au minimum 12 blocs consécutifs à l’attaquant pour annuler la transaction (en réalité, il y a aussi une contrainte de 30 minutes d’avance, mais l’attaquant peut donner une accélération momentanée pour y palier). [1]

[1] A noter qu’aujourd’hui ce “6 blocs + 30 minutes d’avance” est une valeur en dur, totalement arbitraire et qui n’a rien à voir avec le protocole. On pourrait tout à fait la changer pour dire “suis la branche qui a plus de [1/3 x nombre de calculateurs] de blocs supplémentaires”. Le suivi d’un fork est alors conditionné à ce que cette branche soit réellement suivie par plus d’un tiers des calculateurs.