D’ailleurs si vous voulez jouer à qui qu’a la plus grosse performance CPU, installez Sombrero (un logiciel libre de bench), compilez le, et lancez l’évaluation, ça prend cinq minutes:
sudo apt install make gnuplot gcc bc openmpi-bin openmpi-common openssh-server
cd
git clone https://github.com/sa2c/sombrero && cd sombrero
make
./sombrero.sh -n 1 -s small > mon_benchmark_.txt
ça fait plusieurs fois le même test,6 fois pour celui ci, et donne à chaque fois une estimation de FLOPS.
Par exemple mon ordi portable (qui n’est pas une machine de guerre, mais un ultra-portable le Swift7 d’Acer) peut faire jusqu’a 9,6 giga FLOPS.
Un gens a fait un supercalculateur avec 33 raspberry pi qui font 10 Giga FLOPS. C’est drôle mais cher, 1500 eur et surement plus de Watts que mon laptop et son transfo de 45 Watts.
Ce qui ne sert a rien car le hash sha256 n’est qu’une opération mineure dans la PoW, ce n’est pas ce qui occupe la majeure partie du temps de calcul.
Voici ce que fait la PoW a chaque itération :
Incrémentation du nonce
Concaténation du inner hash et du nonce : blockInnerHash ++ nonce (1)
Hash sha512 de (1)
Signature Ed25519 de ce hash sha512
Concaténation du inne hash et de la signature : blockInnerHash ++ blockSig (2)
Hash sha256 de (2)
On voit bien que le hash sha256 n’est que la 6ème étape, et pas la plus coûteuse, bien au contraire.
EDIT: l’observateur avisé notera que l’étape 5 ne sert a rien, on pourrait hasher directement la signature, mais historiquement ça a été fait comme ça, un détail qui pourra être amélioré dans une future version du protocole
Cette étape sert à contextualiser la signature vu que celle-ci n’est pas une fonction bijective (la signature peut correspondre à plusieurs contenus). Mais c’est peut-être de la sur-sécurité je veux bien en convenir.
Étant donné que la signature est déjà la signature du hash sha512 du message, on a déjà tout de contextualiser dans ce hash, le risque de collision étant considéré comme nul, la signature seule est suffisante, c’est sur ce principe que les merkle tree sont basés, et ça marche très bien
Ce serait intéressant de savoir combien il y a de raspberry sur les 80 noeuds… Pas mal à mon avis. Et 10W, ce serait pour un Pi4 avec HDD… Un pi3 avec SD tourne plutôt à 3.6W (mais tout doux). Ça réduit sacrément des i3 à 55W de moyenne.
Perso, je serais partisan de ne faire tourner que sur Pi, ce serait égalitaire et là on aurait la crypto la moins énergivore du monde (c’est déjà la cas, mais encore plus !)
Ça pourrait prendre la forme d’une option de Duniter qui permettrait de publier la config dans BMA (sortie de /proc/cpuinfo, benchmark ou moyenne de hash/s par exemple). On pourrait alors estimer la consommation du réseau plus finement.
Pour des raisons de sécurité et de vie privée, je pense qu’il faut absolument transformer l’info /prox/cpuinfo en quelque chose d’utile pour calculer la conso de duniter, mais pas publier trop d’infos…
Chacun doit rester libre de mettre la puissance qu’il veut à disposition.
Je crois qu’ils sont nombreux à faire tourner duniter sur « ce qu’ils ont » sans se poser plus de questions…
Et puis ceux qui font tourner un serveur en permanence ne le font pas que pour duniter, il y à souvent d’autres services qui tourne dessus. Le Pi ne serait peut pas suffisant…
Ne faire tourner que sur Pi serait une restriction des libertés pas compatible avec la G1
Oui, bien sûr, j’avais pas l’intention de forcer qui que ce soit (et je vois pas comment). C’est juste qu’avec l’algo de puissance de calcul de duniter, ça sert à rien de dépenser 130W quand on peut n’en utiliser que 3.6W… Après chacun est libre d’utiliser un i7 pour calculer du bloc s’il le veut, comme on est libre de rouler dans son 4x4 à 15 litres au cent plutôt qu’en vélo. Je faisais cette reflexion par rapport au titre : duniter peut être énergivore comme il peut être sobre, ça dépend de nous pour beaucoup.
Je ne sais pas si c’est évaluable, mais puisqu’il y a une difficulté de travail personnalisée avec facteur d’exclusion, handicap… pourrait-on évaluer à quel point ce système limite la conso énergétique, par exemple même si on utilisait un ASIC 100% dédié à Duniter ?.. Ça permettrait de montrer à quel point ça serait absurde, et montrerait le caractère vraiment économe de Duniter ?
Un tiers du réseau est constamment exclu du calcul. Ce qui me fait penser que notre communication ne devraient jamais comparer le réseau Duniter entier à un autre système, mais 2/3 du réseau seulement.
Ici par exemple, il ne faut pas afficher 100 serveurs à 55w, mais 2/3*100 serveurs, soit 66 serveurs.
Soit 0,000048 * (2 / 3) = 0,000032 TWh par an !
Donc 38,7 / 0,000032 = 1 209 375 fois moins énergivore que Bitcoin.
Les nœuds exclus ne calculent pas mais sont encore branchés. Ils doivent donc consommer un peu moins mais consomment quand même.
Il faut aussi compter les nœuds non-membres. Avec Conso la consommation moyenne d’un nœud, Nœuds le nombre de nœuds, Membres le nombre de nœuds membres, Pow la variation de consommation entre un nœud qui ne forge pas et un nœud qui forge :
Nœuds × Conso + 2/3 × Membres × Pow
J’aimerais bien avoir un capteur de courant non-invasif, tiens…
Tu es sur de cela ? Avec quel outil calcules-tu le temps d’utilisation d’un processus donné? as-tu fais la différence entre le moment où ce processus calcule et lorsqu’il ne calcule pas (toutes choses égales par ailleurs) ?
Les noeuds qui ne calculent pas (miroirs ou exclus) reçoivent et transmettent les documents à enregistrer, répondent aux requêtes BMA/WS2P… Le processus de preuve de travail est arrété, mais il y a d’autres processus qui, eux, consomment.
Et même si on ne regarde que les opérations strictement liées à la pow, le noeud doit bien observer les blocs qui passent pour savoir quand il peut se remettre à calculer.
Je n’ai pas mesuré, mais on peut le faire facilement (sous GNU/Linux en tout cas) avec des utilitaires comme top ou htop.
Cependant la conso énergétique n’est pas exactement proportionnelle au temps d’utilisation du processeur : l’utilisation du disque dur et du réseau doivent consommer d’une manière non négligeable. (mais je n’ai pas mesuré) De plus, utiliser le réseau entraîne une consommation sur des dizaines d’autres machines (box, routeurs, concentrateurs et je ne sais quoi d’autre, mais aussi les DNS).
le schéma de la consommation Duniter VS Bitcoin datant de 2020 je souhaiterais la mettre à jour pour une présentation. J’ai vu sur le site mis a jour en temps réel que la conso du Bitcoin était passé à 97,11 TWh / an pour septembre 2022 (Quelle est la consommation électrique du réseau Bitcoin ? - bitcoin.fr)
Pourriez-vous me dire ou on en est avec Duniter ?
Et je suis en train de regarder sur différentes études pour y intégrer la consommation du secteur bancaire et de l’extraction de l’or …
Ça n’a pas tellement bougé a priori, le seul moyen de savoir précisément serait de faire des mesures sur des appareils différents, avec des émissions de transactions artificielles (car la charge utile actuelle du réseau consomme sûrement beaucoup moins que la simple gestion technique du réseau).
On peut déjà trouver des infos sur la consommation future de Duniter v2, puisque des blockchains utilisant les mêmes technologies existent déjà à grande échelle (article sur la conso de Polkadot). Certains composants seront plus gourmands, mais ça permettra de gagner en fiabilité et en rapidité. En revanche on n’aura plus besoin de la preuve de travail qui consomme beaucoup (je ne sais pas si à notre échelle ça change grand chose, mais si on grandit c’est sûr que si), donc une bien plus grande proportion de l’énergie sera consommée par du travail “utile”.
Comme @tuxmain, je pense que tu peux garder le chiffre donné pour Duniter V1 en 2020 pour 2022. Je viens de lancer Cesium qui recense 67 serveurs et la moyenne de 55 W par serveur me semble encore pertinente.
Si bitcoin.fr signale que la conso du Bitcoin a plus que doublée en 2 ans (!!??) on peut dire qu’on reste très efficace dans notre rendement (rapport énergie consommée/service rendu) et on le sera encore avec Duniter V2.
