From 1ad12cac5f565d4a75fa3f1d825d36fae4b7bc86 Mon Sep 17 00:00:00 2001
From: Hugo Trentesaux <hugo@trentesaux.fr>
Date: Tue, 25 Oct 2022 11:16:56 +0200
Subject: [PATCH] [traduction] ajoute liens traductions
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
et réorganise contenu pour préparer archivage duniter v1
---
...13-introduction-a-la-toile-de-confiance.md | 1 +
content/blog/2017-05-02-preuve-de-travail.md | 165 ++++++++++++++++++
...8-04-15-la-toile-de-confiance-en-detail.md | 1 +
content/wiki/_index.md | 3 +
content/wiki/about/_index.md | 3 +
content/wiki/about/credits.md | 3 +
content/wiki/contribuer/_index.md | 3 +
.../blockchain-nodejs/architecture-duniter.md | 3 +
.../blockchain-nodejs/preuve-de-travail.md | 161 +----------------
content/wiki/contribuer/rapporter-un-bug.md | 3 +
content/wiki/doc/_index.md | 3 +
content/wiki/doc/installer/index.md | 3 +
content/wiki/g1/_index.md | 3 +
content/wiki/g1/licence-g1.md | 3 +
content/wiki/monnaie-libre/_index.md | 3 +
content/wiki/toile-de-confiance/_index.md | 3 +
.../introduction-a-la-toile-de-confiance.md | 4 +-
.../la-toile-de-confiance-en-detail.md | 4 +-
18 files changed, 210 insertions(+), 162 deletions(-)
create mode 120000 content/blog/2016-05-13-introduction-a-la-toile-de-confiance.md
create mode 100644 content/blog/2017-05-02-preuve-de-travail.md
create mode 120000 content/blog/2018-04-15-la-toile-de-confiance-en-detail.md
mode change 100644 => 120000 content/wiki/contribuer/blockchain-nodejs/preuve-de-travail.md
diff --git a/content/blog/2016-05-13-introduction-a-la-toile-de-confiance.md b/content/blog/2016-05-13-introduction-a-la-toile-de-confiance.md
new file mode 120000
index 0000000..3f45e24
--- /dev/null
+++ b/content/blog/2016-05-13-introduction-a-la-toile-de-confiance.md
@@ -0,0 +1 @@
+../wiki/toile-de-confiance/introduction-a-la-toile-de-confiance.md
\ No newline at end of file
diff --git a/content/blog/2017-05-02-preuve-de-travail.md b/content/blog/2017-05-02-preuve-de-travail.md
new file mode 100644
index 0000000..d8c397b
--- /dev/null
+++ b/content/blog/2017-05-02-preuve-de-travail.md
@@ -0,0 +1,165 @@
++++
+title = "Preuve de travail"
+date = 2017-05-02
+weight = 9
+
+[taxonomies]
+authors = ["cgeek", "elois",]
+
+[extra]
+thumbnail = "/PELICAN/images/races.svg"
+
+[extra.translations]
+en = "blog/2018-11-27-duniter-proof-of-work/"
++++
+
+# Preuve de travail
+
+## À quoi sert la preuve de travail ?
+
+La preuve de travail permet de synchroniser un réseau pair à pair (p2p) de machines devant partager une base de données commune.
+Dans duniter, cette base de données commune est notre grand livre de comptes commun qui consigne toutes les transactions de la monnaie ainsi que les actes de la toile de confiance (certifications, adhésions, renouvellements, révocations, etc). Elle est inscrite dans une « blockchain ».
+Comment fait-on lorsque plusieurs machines souhaitent ajouter en même temps une nouvelle donnée (une nouvelle transaction par exemple) ?
+De plus, comment fait-on pour nous mettre d'accord sur le temps qui s'est écoulé ? Ce qui est essentiel pour savoir s'il est temps de créer le dividende universel ainsi que pour gérer les délais d'expiration des adhésions et certifications.
+
+Eh bien la preuve de travail permet de résoudre ces deux problèmes en même temps.
+
+Voici comment :
+
+1. N'importe quelle machine peut écrire une nouvelle donnée (= un nouveau bloc), mais pour avoir le droit de l'écrire il faut résoudre un défi qui demande du *travail* à la machine, ce défi doit être suffisamment difficile pour qu'il n'y ait pas deux machines qui le résolvent en même temps. Il n'y a donc qu'une seule machine qui peut écrire en même temps, celle qui résout le défi demandé, bien.
+2. La résolution de ce défi demande un certain temps de calcul qui est fonction de la puissance de calcul du réseau, nous avons donc là un moyen de définir l'écoulement du temps selon un référentiel commun. Il suffit ensuite de choisir une convention, par exemple `1 bloc = 5 min` puis d'adapter la difficulté du défi pour que le réseau trouve bien en moyenne un bloc toutes les 5 min.
+
+## Seuls les membres peuvent calculer
+
+Duniter a une différence fondamentale avec toutes les autres crypto-monnaies basées sur la preuve de travail : seuls les membres de la toile de confiance ont le droit d'ajouter des blocs à la blockchain (le grand livre de comptes commun).
+Chaque bloc est signé avec la clé privée du membre qui l'a ajouté, cela permet d'affecter une difficulté personnalisée a chaque membre ce qui change absolument tout, sans ce mécanisme la Ğ1 serait tout aussi asymétrique et non-libre que le bitcoin !
+
+La difficulté personnalisée est en effet indispensable pour empêcher la course au calcul, ainsi que pour empêcher un supercalculateur de prendre le contrôle de toute la blockchain et donc de la monnaie.
+De plus, la difficulté personnalisée impose une rotation dans l'écriture des blocs qui permet a tous d'avoir la possibilité d'écrire dans la blockchain, même avec une brique internet ou un raspberry pi, ce qui rend les monnaies duniter considérablement plus économes en énergie !
+
+## Comment marche la preuve de travail ?
+
+### L'empreinte (le hash)
+
+Exemple d'empreinte valide :
+
+```
+00000276902793AA44601A9D43099E7B63DBF9EBB55BCCFD6AE20C729B54C653
+```
+
+On peut voir que cette empreinte démarre par 5 zéros : réaliser une telle empreinte demande beaucoup de *travail* de la part d'un ordinateur, d'où le fait qu'on appelle l'opération consistant à réaliser une telle empreinte « *preuve de travail* ».
+
+### La difficulté commune
+
+Afin de nous donner une mesure commune du temps, nous avons besoin d'une difficulté commune qui assure que la blockchain avance à un rythme régulier (1 bloc toutes les `avgGenTime` secondes, `avgGenTime` étant l'un des 20 paramètres qui décrivent une monnaie duniter).
+Cette difficulté peut commencer à une valeur arbitraire (`70` dans le code `v1.5.x`) puis agit comme un ressort, si l'intervalle entre deux blocs est inférieur à `avgGenTime` la difficulté commune augmente et inversement si l'intervalle entre deux blocs est supérieur à `avgGenTime`, la difficulté commune diminue.
+
+#### 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 `v1.5.x` 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<sup>ème</sup> 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]`
+
+> Oui mais l'empreinte d'un bloc sera toujours la même pour un bloc donné et n'a aucune raison de commencer par une suite particulière, donc comment fait-on pour trouver un bloc qui a comme par hasard une empreinte qui respecte la difficulté ?
+
+Bien vu, il faut effectivement faire varier le contenu du bloc pour obtenir une empreinte différente, c'est le rôle du Nonce.
+Lorsque qu'un membre veut ajouter un nouveau bloc à la blockchain, il fixe le contenu de ce bloc, puis rajoute un champ Nonce qu'il fait varier jusqu'à tomber par hasard sur une empreinte qui respecte la difficulté.
+
+### Le Nonce
+
+Il s'agit du champ du document `Block` permettant de faire varier l'empreinte finale du bloc, empreinte qui définit le niveau de la preuve de travail.
+
+Exemples de valeurs de Nonce :
+
+* 10100000112275
+* 10300000288743
+* 10400000008538
+* 10700000079653
+* 10300000070919
+
+En réalité ces valeurs de `Nonce` suivent toutes un même schéma `XYY00000000000`. Le Nonce ne correspond pas aux nombres d'essais, mais plutôt à un espace de Nonce possible. La décomposition est la suivante :
+
+* X correspond au numéro de pair. Par exemple celui qui a plusieurs nœuds avec la même clé personnelle et qui sont donc tous capables de calculer, chacun de ces nœuds va réaliser sa preuve avec un X différent, afin de ne pas calculer la même preuve justement. Car potentiellement, ils réalisent exactement le même prochain bloc (puisque l'émetteur est le même, le contenu possiblement identique, seul le Nonce peut varier), donc il faut avoir un Nonce qui les différencie pour qu'ils ne fassent pas exactement les mêmes calculs.
+* Y correspond au numéro de cœur du processeur. On peut voir par exemple que quelqu'un possède au moins 7 cores dans son CPU ici, car on lit le Nonce `107[...]`. Un serveur avec 99 cores pourrait réaliser une preuve `199[...]` par exemple.
+
+Le reste du Nonce, la partie derrière XYY, est l'espace de Nonce du nœud pour chaque core du CPU. Ce qui fait donc un espace de 11 chiffres (`00000000000`) pour trouver un Nonce correct pour chaque core du CPU de la machine (CPU au sens large, ce peut-être un bi-CPU, on considère le nombre de cores résultants pour la PoW).
+
+### La difficulté personnalisée
+
+Nous avons expliqué plus haut que la difficulté personnalisée est **le nouveau concept fondamental** qui différencie les monnaies duniter des autres crypto-monnaies basées sur la « *preuve de travail* », comme le bitcoin par exemple.
+
+Voici donc comment est calculée la difficulté personnalisée d'un membre :
+
+La difficulté personnalisée d'un membre résulte de l'assemblage de deux contraintes distinctes qui ont des rôles complémentaires : le **facteur d'exclusion** et le **handicap**.
+
+Soient `powMin` la difficulté commune, `exFact` le facteur d'exclusion d'un membre et `handicap` son handicap. La difficulté personnalité `diff` de ce membre est :
+
+```
+diff = powMin*exFact + handicap
+```
+
+#### Le facteur d'exclusion `exFact` d'un membre
+
+Les membres qui n'ont jamais écrit de bloc ou qui n'ont pas écrit de bloc depuis longtemps ont un facteur d'exclusion de `1`. Leur difficulté personnalisée sera donc égale à la somme `powMin + handicap`.
+Avant de lire la formule donnée plus bas vous devez comprendre le rôle de ce facteur d'exclusion : lorsqu'un membre ajoute un bloc à la blockchain, son facteur d'exclusion saute subitement de 1 vers une valeur très élevée afin de faire grimper exponentiellement sa difficulté et l'exclure ainsi du calcul des prochains blocs et donc l'empêcher de prendre le contrôle de la blockchain.
+Le facteur d'exclusion du membre va ensuite chuter rapidement à chaque nouveau bloc dont il n'est pas l'auteur puis retomber à 1 au bout d'un nombre de blocs qui est en fait une proportion du nombre de membres calculant (un tiers dans le cas de la Ğ1, ce qui signifie que s'il y a 15 membres calculant vous êtes exclus pendant 5 blocs).
+
+> heu attend c'est quoi le nombre de membres calculant ?
+
+Très bonne question, il s'agit du nombre de membres que l'on considère comme étant actuellement en train de calculer le prochain bloc. En réalité il n'y a aucun moyen de savoir combien de membres sont réellement en train de calculer le prochain bloc car d'une part il est impossible d'avoir une vue complète du réseau et d'autre part il existe des moyens de se rendre invisible du réseau. Il nous faut pourtant bien choisir une méthode, car sans considérer le nombre de membres calculant, il est impossible de calibrer la difficulté personnalisée.
+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.
+
+> Et comment on choisit X ?
+
+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](https://github.com/duniter/duniter/blob/master/doc/Protocol.md#br_g05---headissuersframe) et [BR_G06](https://github.com/duniter/duniter/blob/master/doc/Protocol.md#br_g06---headissuersframevar) du protocole DUP.
+
+> Revenons à notre difficulté personnalisée !
+
+Nous avons dit que le facteur d'exclusion `exFact` augmente brutalement dès que le membre considéré trouve un bloc puis qu'il diminue rapidement pour retomber à `1` au bout d'un nombre de blocs égal au tiers des calculateurs. Et bien, c'est parti voici comment est calculé `exFact` :
+
+Soient `nbPreviousIssuers` la valeur du champ `issuersCount` du dernier bloc trouvé par le membre et `nbBlocksSince` le nombre de blocs trouvés par le reste du réseau depuis que le membre considéré a trouvé son dernier bloc.
+
+```
+exFact = MAX [ 1 ; FLOOR (0.67 * nbPreviousIssuers / (1 + nbBlocksSince)) ]
+```
+
+La fonction FLOOR est une simple troncature, ainsi pour que `exFact` soit excluant il faut que le rapport `(0.67 * nbPreviousIssuers / (1 + nbBlocksSince))` soit supérieur ou égal à 2. On voit bien que si `nbBlocksSince` est supérieur au tiers des calculateurs = `0.33*nbPreviousIssuers` alors le rapport sera inférieur à 2 et donc le membre ne sera pas exclu du calcul du prochain bloc.
+À l'inverse, si le membre considéré est l'auteur du dernier bloc alors `nbBlocksSince=0` et le facteur d'exclusion vaut donc `0.67 * nbPreviousIssuers`, c'est d'autant plus grand que le nombre de calculateurs est élevé. Je vous laisse imaginer la difficulté vertigineuse que vous atteindrez en trouvant un bloc s'il y a des centaines de membres calculant !
+Vous atteindrez une difficulté telle que même le plus grand des supercalcuteurs serait bloqué, et c'est bien le but du facteur d'exclusion : empecher les supercalculateurs et fermes de calcul de prendre le contrôle de la blockchain et donc de la monnaie.
+
+En revanche, a tout instant t les deux tiers des membres calculant non exclus ont tous un facteur d'exclusion égal à `1`, mais tous n'ont pas la même puissance de calcul, et donc si la difficulté personnalisée se limitait au facteur d'exclusion c'est toujours le tiers des membres calculant les plus puissants qui écriraient des blocs et deux tiers restants seraient presque toujours exclus, en particulier les machines très modestes type raspberry n'auraient aucune chance.
+
+#### Le handicap
+
+Le handicap est le second paramètre de la difficulté personnalisée. Plus subtil, il permet néanmoins d'améliorer considérablement le mécanisme de rotation en donnant un handicap aux membres ayant une machine puissante afin de donner leur chance aux machines les plus modestes et de diminuer le coût écologique de la monnaie.
+
+Le calcul du handicap se base sur le nombre médian de blocs écrits par chaque membre au sein de la fenêtre courante. En gros, l'idée est de donner un handicap à la moitié haute de la fenêtre courante pour donner plus de chance à la moitié basse.
+
+Soient `nbPersonalBlocksInFrame` le nombre de blocs écrits par le membre considéré dans la fenêtre courante et `medianOfBlocksInFrame` le nombre médian de blocs écrits par les membres au sein de la fenêtre courante.
+
+Voici la formule :
+
+```
+handicap = FLOOR(LN(MAX(1;(nbPersonalBlocksInFrame + 1) / medianOfBlocksInFrame)) / LN(1.189))
+```
+
+Démystifions cette formule, `(nbPersonalBlocksInFrame + 1) / medianOfBlocksInFrame)` est simplement le rapport entre le nombre de blocs calculés par le membre et la médiane. Par exemple si le membre a calculé `9` blocs dans la fenêtre courante alors que la médiane vaut `5`, ce rapport vaudra `(9+1)/5 = 2`.
+On s'assure via la fonction MAX que ce rapport vaut au moins `1`.
+
+Ensuite 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.
+
+Si l'on veut que le handicap s'applique dés la médiane il faudrait ensuite diviser par `LN(1)`, le problème c'est qu'on a déjà nivellé la rapport à `1` avec la fonction MAX, donc si l'on divisait par `LN(1)` tous les membres calculant auraient un handicap >= `1`, qui plus est, est-il bien juste de donner un handicap à un membre qui est tout juste à la médiane ?
+C'est pourquoi, au lieu de prendre `1`, on prend `1.189`, ce qui veut dire qu'il faut être `18,9 %` au-dessus de la médiane pour subir un handicap (si l'on néglige le +1 dans la formule qui devient effectivement négligeable pour un grand nombre de calculateurs).
+
+Mais pourquoi `18,9%` me direz-vous ?
+C'est 16^(1/16), le facteur de difficulté entre 2 niveaux de la preuve de travail dont le hash est en hexadécimal.
+
+En conclusion, ce qu'il faut retenir c'est l'idée d'indexer le handicap sur le logarithme du rapport à la médiane, et de ne l'appliquer que pour les membres dont le rapport à la médiane dépasse le rapport entre 2 niveaux de difficulté de la preuve de travail.
+
diff --git a/content/blog/2018-04-15-la-toile-de-confiance-en-detail.md b/content/blog/2018-04-15-la-toile-de-confiance-en-detail.md
new file mode 120000
index 0000000..a4d117b
--- /dev/null
+++ b/content/blog/2018-04-15-la-toile-de-confiance-en-detail.md
@@ -0,0 +1 @@
+../wiki/toile-de-confiance/la-toile-de-confiance-en-detail.md
\ No newline at end of file
diff --git a/content/wiki/_index.md b/content/wiki/_index.md
index c7fc2c4..436f3de 100644
--- a/content/wiki/_index.md
+++ b/content/wiki/_index.md
@@ -7,6 +7,9 @@ title = "Wiki"
[taxonomies]
authors = ["HugoTrentesaux", "cgeek", "matiou",]
tags = ["blockchain", "TRM", "yunohost",]
+
+[extra.translations]
+en = "wiki/"
+++
# Wiki
diff --git a/content/wiki/about/_index.md b/content/wiki/about/_index.md
index adf8d72..21c4cf7 100644
--- a/content/wiki/about/_index.md
+++ b/content/wiki/about/_index.md
@@ -7,6 +7,9 @@ weight = 6
[taxonomies]
authors = ["cgeek",]
category = ["Meta",]
+
+[extra.translations]
+en = "wiki/about/"
+++
# À propos
diff --git a/content/wiki/about/credits.md b/content/wiki/about/credits.md
index 971281c..2400abf 100644
--- a/content/wiki/about/credits.md
+++ b/content/wiki/about/credits.md
@@ -6,6 +6,9 @@ aliases = ["fr/credits",]
[taxonomies]
authors = ["cgeek",]
category = ["Meta",]
+
+[extra.translations]
+en = "wiki/about/credits/"
+++
# Crédits
diff --git a/content/wiki/contribuer/_index.md b/content/wiki/contribuer/_index.md
index 2a63d3d..06bfb79 100644
--- a/content/wiki/contribuer/_index.md
+++ b/content/wiki/contribuer/_index.md
@@ -7,6 +7,9 @@ weight = 5
[taxonomies]
authors = ["cgeek", ]
tags = ["blockchain", "TRM", "yunohost",]
+
+[extra.translations]
+en = "wiki/contribute/"
+++
# Contribuer
diff --git a/content/wiki/contribuer/blockchain-nodejs/architecture-duniter.md b/content/wiki/contribuer/blockchain-nodejs/architecture-duniter.md
index a517801..43736aa 100644
--- a/content/wiki/contribuer/blockchain-nodejs/architecture-duniter.md
+++ b/content/wiki/contribuer/blockchain-nodejs/architecture-duniter.md
@@ -6,6 +6,9 @@ weight = 10
[taxonomies]
authors = ["vit",]
+
+[extra.translations]
+en = "wiki/contribute/archive/architecture/"
+++
# Architecture
diff --git a/content/wiki/contribuer/blockchain-nodejs/preuve-de-travail.md b/content/wiki/contribuer/blockchain-nodejs/preuve-de-travail.md
deleted file mode 100644
index a26b36d..0000000
--- a/content/wiki/contribuer/blockchain-nodejs/preuve-de-travail.md
+++ /dev/null
@@ -1,160 +0,0 @@
-+++
-title = "Preuve de travail"
-date = 2017-05-02
-aliases = ["fr/preuve-de-travail",]
-weight = 9
-
-[taxonomies]
-authors = ["cgeek", "elois",]
-+++
-
-# Preuve de travail
-
-## À quoi sert la preuve de travail ?
-
-La preuve de travail permet de synchroniser un réseau pair à pair (p2p) de machines devant partager une base de données commune.
-Dans duniter, cette base de données commune est notre grand livre de comptes commun qui consigne toutes les transactions de la monnaie ainsi que les actes de la toile de confiance (certifications, adhésions, renouvellements, révocations, etc). Elle est inscrite dans une « blockchain ».
-Comment fait-on lorsque plusieurs machines souhaitent ajouter en même temps une nouvelle donnée (une nouvelle transaction par exemple) ?
-De plus, comment fait-on pour nous mettre d'accord sur le temps qui s'est écoulé ? Ce qui est essentiel pour savoir s'il est temps de créer le dividende universel ainsi que pour gérer les délais d'expiration des adhésions et certifications.
-
-Eh bien la preuve de travail permet de résoudre ces deux problèmes en même temps.
-
-Voici comment :
-
-1. N'importe quelle machine peut écrire une nouvelle donnée (= un nouveau bloc), mais pour avoir le droit de l'écrire il faut résoudre un défi qui demande du *travail* à la machine, ce défi doit être suffisamment difficile pour qu'il n'y ait pas deux machines qui le résolvent en même temps. Il n'y a donc qu'une seule machine qui peut écrire en même temps, celle qui résout le défi demandé, bien.
-2. La résolution de ce défi demande un certain temps de calcul qui est fonction de la puissance de calcul du réseau, nous avons donc là un moyen de définir l'écoulement du temps selon un référentiel commun. Il suffit ensuite de choisir une convention, par exemple `1 bloc = 5 min` puis d'adapter la difficulté du défi pour que le réseau trouve bien en moyenne un bloc toutes les 5 min.
-
-## Seuls les membres peuvent calculer
-
-Duniter a une différence fondamentale avec toutes les autres crypto-monnaies basées sur la preuve de travail : seuls les membres de la toile de confiance ont le droit d'ajouter des blocs à la blockchain (le grand livre de comptes commun).
-Chaque bloc est signé avec la clé privée du membre qui l'a ajouté, cela permet d'affecter une difficulté personnalisée a chaque membre ce qui change absolument tout, sans ce mécanisme la Ğ1 serait tout aussi asymétrique et non-libre que le bitcoin !
-
-La difficulté personnalisée est en effet indispensable pour empêcher la course au calcul, ainsi que pour empêcher un supercalculateur de prendre le contrôle de toute la blockchain et donc de la monnaie.
-De plus, la difficulté personnalisée impose une rotation dans l'écriture des blocs qui permet a tous d'avoir la possibilité d'écrire dans la blockchain, même avec une brique internet ou un raspberry pi, ce qui rend les monnaies duniter considérablement plus économes en énergie !
-
-## Comment marche la preuve de travail ?
-
-### L'empreinte (le hash)
-
-Exemple d'empreinte valide :
-
-```
-00000276902793AA44601A9D43099E7B63DBF9EBB55BCCFD6AE20C729B54C653
-```
-
-On peut voir que cette empreinte démarre par 5 zéros : réaliser une telle empreinte demande beaucoup de *travail* de la part d'un ordinateur, d'où le fait qu'on appelle l'opération consistant à réaliser une telle empreinte « *preuve de travail* ».
-
-### La difficulté commune
-
-Afin de nous donner une mesure commune du temps, nous avons besoin d'une difficulté commune qui assure que la blockchain avance à un rythme régulier (1 bloc toutes les `avgGenTime` secondes, `avgGenTime` étant l'un des 20 paramètres qui décrivent une monnaie duniter).
-Cette difficulté peut commencer à une valeur arbitraire (`70` dans le code `v1.5.x`) puis agit comme un ressort, si l'intervalle entre deux blocs est inférieur à `avgGenTime` la difficulté commune augmente et inversement si l'intervalle entre deux blocs est supérieur à `avgGenTime`, la difficulté commune diminue.
-
-#### 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 `v1.5.x` 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<sup>ème</sup> 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]`
-
-> Oui mais l'empreinte d'un bloc sera toujours la même pour un bloc donné et n'a aucune raison de commencer par une suite particulière, donc comment fait-on pour trouver un bloc qui a comme par hasard une empreinte qui respecte la difficulté ?
-
-Bien vu, il faut effectivement faire varier le contenu du bloc pour obtenir une empreinte différente, c'est le rôle du Nonce.
-Lorsque qu'un membre veut ajouter un nouveau bloc à la blockchain, il fixe le contenu de ce bloc, puis rajoute un champ Nonce qu'il fait varier jusqu'à tomber par hasard sur une empreinte qui respecte la difficulté.
-
-### Le Nonce
-
-Il s'agit du champ du document `Block` permettant de faire varier l'empreinte finale du bloc, empreinte qui définit le niveau de la preuve de travail.
-
-Exemples de valeurs de Nonce :
-
-* 10100000112275
-* 10300000288743
-* 10400000008538
-* 10700000079653
-* 10300000070919
-
-En réalité ces valeurs de `Nonce` suivent toutes un même schéma `XYY00000000000`. Le Nonce ne correspond pas aux nombres d'essais, mais plutôt à un espace de Nonce possible. La décomposition est la suivante :
-
-* X correspond au numéro de pair. Par exemple celui qui a plusieurs nœuds avec la même clé personnelle et qui sont donc tous capables de calculer, chacun de ces nœuds va réaliser sa preuve avec un X différent, afin de ne pas calculer la même preuve justement. Car potentiellement, ils réalisent exactement le même prochain bloc (puisque l'émetteur est le même, le contenu possiblement identique, seul le Nonce peut varier), donc il faut avoir un Nonce qui les différencie pour qu'ils ne fassent pas exactement les mêmes calculs.
-* Y correspond au numéro de cœur du processeur. On peut voir par exemple que quelqu'un possède au moins 7 cores dans son CPU ici, car on lit le Nonce `107[...]`. Un serveur avec 99 cores pourrait réaliser une preuve `199[...]` par exemple.
-
-Le reste du Nonce, la partie derrière XYY, est l'espace de Nonce du nœud pour chaque core du CPU. Ce qui fait donc un espace de 11 chiffres (`00000000000`) pour trouver un Nonce correct pour chaque core du CPU de la machine (CPU au sens large, ce peut-être un bi-CPU, on considère le nombre de cores résultants pour la PoW).
-
-### La difficulté personnalisée
-
-Nous avons expliqué plus haut que la difficulté personnalisée est **le nouveau concept fondamental** qui différencie les monnaies duniter des autres crypto-monnaies basées sur la « *preuve de travail* », comme le bitcoin par exemple.
-
-Voici donc comment est calculée la difficulté personnalisée d'un membre :
-
-La difficulté personnalisée d'un membre résulte de l'assemblage de deux contraintes distinctes qui ont des rôles complémentaires : le **facteur d'exclusion** et le **handicap**.
-
-Soient `powMin` la difficulté commune, `exFact` le facteur d'exclusion d'un membre et `handicap` son handicap. La difficulté personnalité `diff` de ce membre est :
-
-```
-diff = powMin*exFact + handicap
-```
-
-#### Le facteur d'exclusion `exFact` d'un membre
-
-Les membres qui n'ont jamais écrit de bloc ou qui n'ont pas écrit de bloc depuis longtemps ont un facteur d'exclusion de `1`. Leur difficulté personnalisée sera donc égale à la somme `powMin + handicap`.
-Avant de lire la formule donnée plus bas vous devez comprendre le rôle de ce facteur d'exclusion : lorsqu'un membre ajoute un bloc à la blockchain, son facteur d'exclusion saute subitement de 1 vers une valeur très élevée afin de faire grimper exponentiellement sa difficulté et l'exclure ainsi du calcul des prochains blocs et donc l'empêcher de prendre le contrôle de la blockchain.
-Le facteur d'exclusion du membre va ensuite chuter rapidement à chaque nouveau bloc dont il n'est pas l'auteur puis retomber à 1 au bout d'un nombre de blocs qui est en fait une proportion du nombre de membres calculant (un tiers dans le cas de la Ğ1, ce qui signifie que s'il y a 15 membres calculant vous êtes exclus pendant 5 blocs).
-
-> heu attend c'est quoi le nombre de membres calculant ?
-
-Très bonne question, il s'agit du nombre de membres que l'on considère comme étant actuellement en train de calculer le prochain bloc. En réalité il n'y a aucun moyen de savoir combien de membres sont réellement en train de calculer le prochain bloc car d'une part il est impossible d'avoir une vue complète du réseau et d'autre part il existe des moyens de se rendre invisible du réseau. Il nous faut pourtant bien choisir une méthode, car sans considérer le nombre de membres calculant, il est impossible de calibrer la difficulté personnalisée.
-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.
-
-> Et comment on choisit X ?
-
-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](https://github.com/duniter/duniter/blob/master/doc/Protocol.md#br_g05---headissuersframe) et [BR_G06](https://github.com/duniter/duniter/blob/master/doc/Protocol.md#br_g06---headissuersframevar) du protocole DUP.
-
-> Revenons à notre difficulté personnalisée !
-
-Nous avons dit que le facteur d'exclusion `exFact` augmente brutalement dès que le membre considéré trouve un bloc puis qu'il diminue rapidement pour retomber à `1` au bout d'un nombre de blocs égal au tiers des calculateurs. Et bien, c'est parti voici comment est calculé `exFact` :
-
-Soient `nbPreviousIssuers` la valeur du champ `issuersCount` du dernier bloc trouvé par le membre et `nbBlocksSince` le nombre de blocs trouvés par le reste du réseau depuis que le membre considéré a trouvé son dernier bloc.
-
-```
-exFact = MAX [ 1 ; FLOOR (0.67 * nbPreviousIssuers / (1 + nbBlocksSince)) ]
-```
-
-La fonction FLOOR est une simple troncature, ainsi pour que `exFact` soit excluant il faut que le rapport `(0.67 * nbPreviousIssuers / (1 + nbBlocksSince))` soit supérieur ou égal à 2. On voit bien que si `nbBlocksSince` est supérieur au tiers des calculateurs = `0.33*nbPreviousIssuers` alors le rapport sera inférieur à 2 et donc le membre ne sera pas exclu du calcul du prochain bloc.
-À l'inverse, si le membre considéré est l'auteur du dernier bloc alors `nbBlocksSince=0` et le facteur d'exclusion vaut donc `0.67 * nbPreviousIssuers`, c'est d'autant plus grand que le nombre de calculateurs est élevé. Je vous laisse imaginer la difficulté vertigineuse que vous atteindrez en trouvant un bloc s'il y a des centaines de membres calculant !
-Vous atteindrez une difficulté telle que même le plus grand des supercalcuteurs serait bloqué, et c'est bien le but du facteur d'exclusion : empecher les supercalculateurs et fermes de calcul de prendre le contrôle de la blockchain et donc de la monnaie.
-
-En revanche, a tout instant t les deux tiers des membres calculant non exclus ont tous un facteur d'exclusion égal à `1`, mais tous n'ont pas la même puissance de calcul, et donc si la difficulté personnalisée se limitait au facteur d'exclusion c'est toujours le tiers des membres calculant les plus puissants qui écriraient des blocs et deux tiers restants seraient presque toujours exclus, en particulier les machines très modestes type raspberry n'auraient aucune chance.
-
-#### Le handicap
-
-Le handicap est le second paramètre de la difficulté personnalisée. Plus subtil, il permet néanmoins d'améliorer considérablement le mécanisme de rotation en donnant un handicap aux membres ayant une machine puissante afin de donner leur chance aux machines les plus modestes et de diminuer le coût écologique de la monnaie.
-
-Le calcul du handicap se base sur le nombre médian de blocs écrits par chaque membre au sein de la fenêtre courante. En gros, l'idée est de donner un handicap à la moitié haute de la fenêtre courante pour donner plus de chance à la moitié basse.
-
-Soient `nbPersonalBlocksInFrame` le nombre de blocs écrits par le membre considéré dans la fenêtre courante et `medianOfBlocksInFrame` le nombre médian de blocs écrits par les membres au sein de la fenêtre courante.
-
-Voici la formule :
-
-```
-handicap = FLOOR(LN(MAX(1;(nbPersonalBlocksInFrame + 1) / medianOfBlocksInFrame)) / LN(1.189))
-```
-
-Démystifions cette formule, `(nbPersonalBlocksInFrame + 1) / medianOfBlocksInFrame)` est simplement le rapport entre le nombre de blocs calculés par le membre et la médiane. Par exemple si le membre a calculé `9` blocs dans la fenêtre courante alors que la médiane vaut `5`, ce rapport vaudra `(9+1)/5 = 2`.
-On s'assure via la fonction MAX que ce rapport vaut au moins `1`.
-
-Ensuite 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.
-
-Si l'on veut que le handicap s'applique dés la médiane il faudrait ensuite diviser par `LN(1)`, le problème c'est qu'on a déjà nivellé la rapport à `1` avec la fonction MAX, donc si l'on divisait par `LN(1)` tous les membres calculant auraient un handicap >= `1`, qui plus est, est-il bien juste de donner un handicap à un membre qui est tout juste à la médiane ?
-C'est pourquoi, au lieu de prendre `1`, on prend `1.189`, ce qui veut dire qu'il faut être `18,9 %` au-dessus de la médiane pour subir un handicap (si l'on néglige le +1 dans la formule qui devient effectivement négligeable pour un grand nombre de calculateurs).
-
-Mais pourquoi `18,9%` me direz-vous ?
-C'est 16^(1/16), le facteur de difficulté entre 2 niveaux de la preuve de travail dont le hash est en hexadécimal.
-
-En conclusion, ce qu'il faut retenir c'est l'idée d'indexer le handicap sur le logarithme du rapport à la médiane, et de ne l'appliquer que pour les membres dont le rapport à la médiane dépasse le rapport entre 2 niveaux de difficulté de la preuve de travail.
-
diff --git a/content/wiki/contribuer/blockchain-nodejs/preuve-de-travail.md b/content/wiki/contribuer/blockchain-nodejs/preuve-de-travail.md
new file mode 120000
index 0000000..deb0cde
--- /dev/null
+++ b/content/wiki/contribuer/blockchain-nodejs/preuve-de-travail.md
@@ -0,0 +1 @@
+../../../blog/2017-05-02-preuve-de-travail.md
\ No newline at end of file
diff --git a/content/wiki/contribuer/rapporter-un-bug.md b/content/wiki/contribuer/rapporter-un-bug.md
index c8fc7d1..e105b2a 100644
--- a/content/wiki/contribuer/rapporter-un-bug.md
+++ b/content/wiki/contribuer/rapporter-un-bug.md
@@ -7,6 +7,9 @@ weight = 9
[taxonomies]
authors = ["cgeek",]
category = ["Meta",]
+
+[extra.translations]
+en = "wiki/contribute/report-a-bug"
+++
# Rapporter un bug
diff --git a/content/wiki/doc/_index.md b/content/wiki/doc/_index.md
index 896fd04..82d4456 100644
--- a/content/wiki/doc/_index.md
+++ b/content/wiki/doc/_index.md
@@ -4,6 +4,9 @@ weight = 1
sort_by = "weight"
aliases = ["fr/miner-des-blocs"]
+
+[extra.translations]
+en = "wiki/doc/"
+++
{% note(type="warning", markdown="true") %}
diff --git a/content/wiki/doc/installer/index.md b/content/wiki/doc/installer/index.md
index 7343cd6..a92d909 100644
--- a/content/wiki/doc/installer/index.md
+++ b/content/wiki/doc/installer/index.md
@@ -6,6 +6,9 @@ title = "Installer un nœud Duniter"
[taxonomies]
authors = ["cgeek",]
+
+[extra.translations]
+en = "wiki/doc/install/"
+++
# Installer un nœud Duniter
diff --git a/content/wiki/g1/_index.md b/content/wiki/g1/_index.md
index 350a30b..c57e0c2 100644
--- a/content/wiki/g1/_index.md
+++ b/content/wiki/g1/_index.md
@@ -1,6 +1,9 @@
+++
title = "Monnaie Äž1"
weight = 3
+
+[extra.translations]
+en = "wiki/g1/"
+++
# Monnaie ÄŸ1
diff --git a/content/wiki/g1/licence-g1.md b/content/wiki/g1/licence-g1.md
index 0c3463c..38cf90f 100644
--- a/content/wiki/g1/licence-g1.md
+++ b/content/wiki/g1/licence-g1.md
@@ -6,6 +6,9 @@ title = "Licence Äž1"
[taxonomies]
authors = ["cgeek", "Galuel",]
+
+[extra.translations]
+en = "wiki/g1/g1-license/"
+++
# Licence Äž1
diff --git a/content/wiki/monnaie-libre/_index.md b/content/wiki/monnaie-libre/_index.md
index 9b62fb3..5ba09d4 100644
--- a/content/wiki/monnaie-libre/_index.md
+++ b/content/wiki/monnaie-libre/_index.md
@@ -8,6 +8,9 @@ toc_depth = 2
[taxonomies]
tags = ["TRM",]
+
+[extra.translations]
+en = "wiki/libre-money/"
+++
{% note(markdown=true, display="block", type="info") %}
diff --git a/content/wiki/toile-de-confiance/_index.md b/content/wiki/toile-de-confiance/_index.md
index 98df407..2bd4358 100644
--- a/content/wiki/toile-de-confiance/_index.md
+++ b/content/wiki/toile-de-confiance/_index.md
@@ -3,6 +3,9 @@ title = "Toile de confiance"
weight = 4
aliases = ["fr/toile-de-confiance"]
+
+[extra.translations]
+en = "wiki/web-of-trust/"
+++
# La Toile de Confiance
diff --git a/content/wiki/toile-de-confiance/introduction-a-la-toile-de-confiance.md b/content/wiki/toile-de-confiance/introduction-a-la-toile-de-confiance.md
index be0abfd..2f0cea5 100644
--- a/content/wiki/toile-de-confiance/introduction-a-la-toile-de-confiance.md
+++ b/content/wiki/toile-de-confiance/introduction-a-la-toile-de-confiance.md
@@ -2,7 +2,6 @@
title = "Fonctionnement de la toile de confiance"
date = 2016-05-13
weight = 1
-aliases = ["introduction-a-la-toile-de-confiance", "/fr/toile-de-confiance/introduction-a-la-toile-de-confiance/"]
[extra]
thumbnail = "/PELICAN/images/network.svg"
@@ -10,6 +9,9 @@ thumbnail = "/PELICAN/images/network.svg"
[taxonomies]
authors = ["greyzlii", "elois",]
tags = ["toile de confiance",]
+
+[extra.translations]
+en = "wiki/web-of-trust/introducing-web-of-trust/"
+++
# Fonctionnement de la toile de confiance
diff --git a/content/wiki/toile-de-confiance/la-toile-de-confiance-en-detail.md b/content/wiki/toile-de-confiance/la-toile-de-confiance-en-detail.md
index 272d908..ae40511 100644
--- a/content/wiki/toile-de-confiance/la-toile-de-confiance-en-detail.md
+++ b/content/wiki/toile-de-confiance/la-toile-de-confiance-en-detail.md
@@ -2,7 +2,6 @@
title = "La toile de confiance en détail"
date = 2018-04-15
weight = 2
-aliases = ["la-toile-de-confiance-en-detail", "fr/toile-de-confiance/la-toile-de-confiance-en-detail"]
[extra]
thumbnail = "/PELICAN/images/network.svg"
@@ -10,6 +9,9 @@ thumbnail = "/PELICAN/images/network.svg"
[taxonomies]
authors = ["elois",]
tags = ["toile de confiance",]
+
+[extra.translations]
+en = "wiki/web-of-trust/duniter-deep-dive-wot/"
+++
# La toile de confiance en détail
--
GitLab