Block issuance distribution

Archives Discussion
2

No this wasn’t what I planned to do, I wanted to start with the very simple algorithm, which is the one we currently have: the issuer of a block has temporary handicap, which depends of the number of previous issuers. So the more we have (member) nodes on the network, the more we have issuers, the longer is the handicap for each particular node.

Here, you can see the effects of the algorithm on less than 20 nodes. But have you considered what it looked like when we had 1 node? 2 nodes? 5, 9, 13? You will probably see a very different distribution, because changing of scale triggers new scale effects.

So here, you have to consider that Duniter only has less than 20 nodes on its network, compared to Bitcoin which has at least 10 times more nodes. The effects of Duniter algorithm are difficulty to see right now because the quantity of nodes is too low for now. A second thing is that Bitcoin miners can gather themselves in large mining pools, which is not possible in Duniter (or very improbable).

So finally my opinion is that it’s rather Bitcoin which, with its mining pool possibility, looks like a Duniter network of 20 nodes. :slight_smile:

Edit:

Please note that we have thought to change the current rule to something like the one you expect for several months. I will try to make something for the next protocol version (0.4).

1 Like
3

Now that 0.40 has been released, we will be able to see the new distribution of blockchain writing in few days.

4

New difficulty distribution seems fine:

Minimal Proof-of-Work: 76 to match `0000[0-3]*`
Difficulty to generate next block n°47518 for 9/12 nodes:
| uid        |   level |
|------------+---------|
| vincentux  |      76 |
| squeeekgps |      76 |
| RavanH     |      76 |
| Jean-F     |      76 |
| modulix    |      77 |
| nay4       |      80 |
| gnu-tux    |      81 |
| ktorn      |      81 |
| pafzedog   |      83 |
| gege53     |     152 |
| kimamila   |     228 |
| cgeek      |     306 |
2 Likes
5

Yes it’s better. Let’s see in few days what the difficulty will look like when we have more nodes in 0.40, because at the moment it is quite hard to compute blocks and have a scaled difficulty.

6

New silkaj feature which display matches that each node needs to accomplish:

Minimal Proof-of-Work: 76 to match `0000[0-3]*`
Difficulty to generate next block n°47521 for 10/14 nodes:
|   level | uid        | match                |
|---------+------------+----------------------|
|      76 | squeeekgps | 0000[0-3]*           |
|      76 | gege53     | 0000[0-3]*           |
|      76 | RavanH     | 0000[0-3]*           |
|      76 | Jean-F     | 0000[0-3]*           |
|      77 | modulix    | 0000[0-2]*           |
|      78 | cgeek      | 0000[0-1]*           |
|      80 | ktorn      | 00000*               |
|      80 | nay4       | 00000*               |
|      81 | gnu-tux    | 00000[0-E]*          |
|      83 | pafzedog   | 00000[0-C]*          |
|     152 | Galuel     | 000000000[0-7]*      |
|     228 | moul       | 00000000000000[0-B]* |
|     381 | vincentux  | 00000000000000000000 |
|     761 | kimamila   | 00000000000000000000 |
3 Likes
7

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
8

It’s already a spectacular result :clap:

1 Like
9

Very good indeed. :thumbsup:

10

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

Capture du 2016-10-21 13-42-26.png1110×654 76.3 KB

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
11

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.

12

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
13

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?

14

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 !

15

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.

16

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

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.

18

Ha bien vu :wink:
il me manquait cette info

Alors je vote haut la main pour la version 0.4 !

19

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…

20

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:)

21

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…)