OK j’essaie d’en préparer un ce soir alors. On est sur quelle durée de présentation ? Genre 5-10 minutes si j’en crois le nombre d’intervenants, non (4 intervenants + questions / réponses, le tout en une demie heure) ?
Tu auras 20 minutes Max pour présenter la chose, c’est pourquoi je te présenterais brièvement en quelques mots afin de donner toute la place à ta présentation diaporamique.
Les questions suivront alors et pourront empiéter sur les petits fours jusqu’a 1h du mat comme la dernière fois (je m’en occuperais si tu veux).
1 Like
Ah oui c’est 1h30, pas 30 minutes, pour tout le monde, mea culpa. Bon ben ça ira alors ça sera pas trop express non plus. Ouf !
1 Like
Je vais finir par déménager à Toulouse…
4 Likes
Fais signe si t’as besoin d’un squat pour chercher un appart’ ^^
1 Like
@elois je me pose une question par rapport au facteur d’exclusion : quand il est très élevé, la machine essaie de calculer même si ça ne sert à rien ou est-ce qu’il y a un système genre “houla c’est même pas la peine avec une difficulté monstrueuse vu que je viens de calculer un blox, autant dormir jusqu’au prochain bloc” ?
Edit : question bonus : la taille des fenêtres pour le handicap et le facteur d’exclusion c’est quel ordre de grandeur pour la Ğ1 ?
1 Like
La machine s’arrête quand elle n’a aucune chance de trouver 
En terme d’ordre de grandeur, il me semble que 1/3 des calculateurs sont constamment exclus. Un deuxième tiers est en difficulté. Le 3ème tiers c’est ceux qui ont pas trouvé de blocs depuis un moment. (en gros)
2 Likes
Actuellement ça ressemble à ça :
- 1/3 est exclu
- 2/3 cherchent
silkaj diffi
Minimal Proof-of-Work: 89 to match `00000[0-6]*`
Difficulty to generate next block n°131910 for 24/35 nodes:
| uid | match | Π diffi | Σ diffi |
|------------------+----------------------+--------------+-----------|
| Darcidride | 00000000000000000000 | 1.3 × 10^154 | 2049 |
| Taskede | 00000000000000000000 | 8.5 × 10^73 | 979 |
| deem | 00000000000000000000 | 1.8 × 10^47 | 626 |
| vincentux | 00000000000000000000 | 4.5 × 10^33 | 446 |
| oaktree | 00000000000000000000 | 2.5 × 10^27 | 360 |
| ji_emme | 00000000000000000* | 3.0 × 10^20 | 272 |
| Patrice_F | 0000000000000000[0-3 | 2.2 × 10^20 | 268 |
| BenoitLavenier | 00000000000[0-B]* | 7.0 × 10^13 | 180 |
| gerard94 | 00000000000[0-C]* | 5.3 × 10^13 | 179 |
| nicoleC | 00000000000[0-D]* | 3.5 × 10^13 | 178 |
| nay4 | 00000000000[0-D]* | 3.5 × 10^13 | 178 |
| DamageCo | 00000[0-2]* | 1.4 × 10^7 | 93 |
| elois | 00000[0-2]* | 1.4 × 10^7 | 93 |
| DYves62 | 00000[0-3]* | 1.3 × 10^7 | 92 |
| moul | 00000[0-3]* | 1.3 × 10^7 | 92 |
| Felipe | 00000[0-3]* | 1.3 × 10^7 | 92 |
| gege53 | 00000[0-4]* | 1.2 × 10^7 | 91 |
| cgeek | 00000[0-4]* | 1.2 × 10^7 | 91 |
| aguy | 00000[0-4]* | 1.2 × 10^7 | 91 |
| pafzedog | 00000[0-4]* | 1.2 × 10^7 | 91 |
| Mententon | 00000[0-5]* | 1.0 × 10^7 | 90 |
| lamessen | 00000[0-6]* | 9.4 × 10^6 | 89 |
| paidge | 00000[0-6]* | 9.4 × 10^6 | 89 |
| SimonLefort | 00000[0-6]* | 9.4 × 10^6 | 89 |
| Crazypanda | 00000[0-6]* | 9.4 × 10^6 | 89 |
| kindlyfire | 00000[0-6]* | 9.4 × 10^6 | 89 |
| BnimajneB | 00000[0-6]* | 9.4 × 10^6 | 89 |
| piaaf31 | 00000[0-6]* | 9.4 × 10^6 | 89 |
| Melua | 00000[0-6]* | 9.4 × 10^6 | 89 |
| MarcelDoppagne | 00000[0-6]* | 9.4 × 10^6 | 89 |
| binuts | 00000[0-6]* | 9.4 × 10^6 | 89 |
| jeanlucdonnadieu | 00000[0-6]* | 9.4 × 10^6 | 89 |
| inso | 00000[0-6]* | 9.4 × 10^6 | 89 |
| Pol | 00000[0-6]* | 9.4 × 10^6 | 89 |
| Julien_Jardin | 00000[0-6]* | 9.4 × 10^6 | 89 |
3 Likes
il manque l’atténuation de la difficulté au fur et à mesure des nouveau bloc, sinon très vite, tout les membre seraient exclu par une difficulté aberrante.
Du coup, en quelques mots, comment la difficulté crois : en forgeant un bloc (et avec l’historique des bloc forgé durant les N dernier blocs)
comment elle décrois ?
il y a 2 notion, l’exclusion à difficulté exponentielle, qui dépend de ?
le handicap qui dépend de ?
Avec la fenêtre des membres calculant sur les N derniers bloc comme référentiel ou l’un ? l’autre ? Bref, j’ai l’impression d’en comprendre suffisement pour comprendre pourquoi ça marche, mais pas assez pour pouvoir l’expliquer clairement.
En ce cas, je t’invite a lire la fin de cette page : https://duniter.org/fr/wiki/duniter/preuve-de-travail/
1 Like
merci, je viens de lire ça, mais ce n’est pas si clair que ça pour moi :
Gràce au concept de fenêtre courante, X correspond alors à la taille de la fenêtre courante, voici comment cela fonctionne : On nomme issuersFrame la taille de la fenêtre courante et issuersCount le nombre de membres ayant calculé au moins 1 bloc dans la fenêtre courante.
Au commencement d’une blockchain, le tout premier bloc que l’on nomme le bloc #0 décrète que issuersFrame=1 et issuersCount=0. Hé oui le tout dernier bloc étant exclu, il n’y a pour l’instant aucun membre dans la fenêtre courante.
Ensuite, à chaque nouveau bloc, on mesure la variation de issuersCount, dès le second bloc (le bloc #1), l’auteur du bloc #0 entre dans la fenêtre courante, on écrira donc dans le bloc #1 issuersCount=1.
issuersFrame varie alors de la façon suivante : si issuersCount augmente de X (et X = 1 au maximum), alors issuersFrame augmentera de 1 unité pendant 5X blocs. Et inversement : si issuersCount diminue de Y (et Y = 2 au maximum : décalage de fenêtre + perte d’un auteur), alors issuersFrame diminuera de 1 unité pendant 5Y blocs. Les effets étant cumulatifs dans le temps. Ce qui fait que si un nouvel auteur apparaît au bloc T et un autre disparaît à T+1, issuersFrame augmentera de 1 unité à T+1 puis diminuera de 1 unité à T+2, pour se stabiliser.
Techniquement ce calcul est formalisé par les règles BR_G05 et BR_G06 du protocole DUP.
Ok, j’ai le détail de la formule, mais pas le comportement global pour m’en faire une idée intuitive.
Actuellement, c’est via rémuniter que je visualise la fenêtre courante, mais même avec ce paragraphe, j’aurais bien du mal à dire pourquoi elle fait cette taille et pas une autre.
En considérant que sur les 15 derniers jours, 100 membres se répartissent de façon homogène les bloc. Combien de bloc contiendra la fenêtre courante ? idem pour 10 membres sur les 15 derniers jours et pour 1000 membres sur les 15 derniers jours (ou plus si ça dépasse)
Sachant qu’il y a un bloc tout les 5 min en moyenne, ça me permet de connaitre la taille temporelle de la fenêtre courante en fonction du nombre de membre différent qu’elle contient, tout en sachant qu’elle a un peu d’inertie mais pas trop pour gérer la variation du nombre de membre calculant dans le temps.
Bref, si je peux avoir d’une part ces 3 exemples, et idéalement une explication de l’ordre de grandeur souhaité, sans aller au niveau de détail de l’implémentation pour l’obtenir, ça m’intéresserait (et peut-être les lecteurs de l’article sur la preuve de travail également).
C’est une fonction récursive : pour connaître la taille de la fenêtre au bloc N, je regarde la taille de la fenêtre au block N-1 et j’y ajoute les variations (négatives ou positives) qui au maximum sont de -1 ou 1.
Partons d’un cas stable :
- au bloc #99994 la fenêtre est de 156 blocs (= 31 émetteurs * 5 + 1), variations = 0.
- au bloc #99995 la fenêtre est toujours de 156 blocs, toutefois un nouvel émetteur inconnu ajoute un cumul de variations à venir de 5 (= 5 * 1 émetteur).
- au bloc #99996 la fenêtre passe donc à 157 blocs, mais un nouvel émetteur arrive encore à ce moment, et donc le cumul de variation à venir est de 9 (5 - 1 + (5 * 1 émetteur)
- au bloc #99997 la fenêtre passe donc à 158 blocs, et le cumul de variation passe à 8
- au bloc #99998 la fenêtre passe donc à 159 blocs, et le cumul de variation passe à 7
- au bloc #99999 la fenêtre passe donc à 160 blocs, et le cumul de variation passe à 6
- au bloc #100001 la fenêtre passe donc à 161 blocs, et le cumul de variation passe à 5
- au bloc #100002 la fenêtre passe donc à 162 blocs, et le cumul de variation passe à 4
- au bloc #100003 la fenêtre passe donc à 163 blocs, et le cumul de variation passe à 3
- au bloc #100004 la fenêtre passe donc à 164 blocs, et le cumul de variation passe à 2
- au bloc #100005 la fenêtre passe donc à 165 blocs, et le cumul de variation passe à 1
- au bloc #100006 la fenêtre passe donc à 166 blocs, et le cumul de variation passe à 0
- au bloc #100007 la fenêtre passe donc à 166 blocs, et le cumul de variation passe à 0
- au bloc #100008 la fenêtre passe donc à 166 blocs, et le cumul de variation passe à 0
- … jusqu’à la prochaine variation ! +5 si nouvel émetteur (il n’y en a qu’un tout au plus, forcément !), -5 si un émetteur sort (il n’y en a qu’un tout au plus, forcément)
Cette fonction fait que : je pars de l’inertie, et à la moindre variation je la note et la distribue sur les blocs suivants.
1 Like
J’ai bien compris que c’était une fonction récurcive, mais pour beaucoup de fonction récurcive, on peu, au moins pour certaines situation (stable par exemple), les exprimer sans le coté récurcif.
Avec tes explication j’une fois stabilisé on a :
fenêtre = nombre d’émetteurs * 5 +1
mais :
nombre d’émetteurs = nombre de membres différents ayant émis au moins une bloc dans la fenêtre courante.
D’où le fait que ça se morde la que, d’où le fait que la fonction soit récursive avec inertie pour y répondre.
PS : les bloc #100007 et #100008 devraient être resté avec une fenêtre à 166 blocs non ?
PS2 : du coup, le handicap ne tiens compte que des bloc de la fenêtre courante sans plus de mémoire du passée ?
Oui bien vu, j’ai corrigé. D’ailleurs si tu cliques sur le lien vers le bloc, tu retrouves le chiffre 166.
La fenêtre courante est notre référentiel de calcul, oui. Seuls ses blocs sont interprétables.
2 Likes