Fonctionnement d'une pool, théorie/algorithme
-
@aabbfive a dit dans Fonctionnement pool :
, le concept de pool m’intéresse beaucoup mais pas forcément pour la cryptomonnaie mais pour le calcul en cluster.
Sur cette question je me baserai sur le algorithme de PoW du BTC.
Si une âme sympathique serrai m’expliquer comment une pool arrive à faire travailler une même cible(block) en divPlop,
Plusieurs pool sont sur Github par exemple :
https://github.com/electroneum/electroneum-pool -
Un pti début de réponse :
Le nonce magique -
@raoullevert Certaines notions me paraissent encore flou.
L’algorithme de PoW du btc ce résume à sa:
Je choisis une cible(difficulté), ainsi que 256 représente la taille d’un block.
J’incrémente le nonce pour que le block compute sois plus petit que A=2^(256-Difficulté).
Le seul moyen pour que le block compute qui est sensé faire 256bits sois plus petit qu’une cible de 256bits, c’est qu’il y ai un/des 0 au début.
Maintenant je retourne la question ^_^
Comment les pools parallélise le calcul, j’aimerai bien obtenir une réponse théorique et pas obtenir le code source d’une pool, ici le bute est de comprendre. -
En gros, tu as tes données d’entrée :
Le hash du bloc précédent
Toutes les transactions qui n’ont pas été inventoriées
Un nombre aléatoire (aussi appelé nonce)Tu t’arrange pour que le hash de tout cas commence par un certain nombre de 0.
Tu ne peux que changer le nonce pour que çà corresponde. Un fois que tu as essayé toutes les possibilité, tu incrémentes l’extranonce, tu remets le nonce à 0 et tu recommences.Donc ton pool doit te donner une plage de nonce (genre 0-100) ou d’extranonce.
-
@raoullevert donc si je comprend bien il donne des plages de nonce ex:
A: 1-1000
B:1000-2000
etc…
Quand A à use tout sa plage et qu’il n’a pas su trouver le block < target, incrémentent le nonce il redemande une plage? -
Ou alors tu peux miner totalement au pif. Vu le faible taux de collision, ça peux le faire aussi.
-
var newJob = {
id: utils.uid(),
extraNonce: currentBlockTemplate.extraNonce,
height: currentBlockTemplate.height,
difficulty: this.difficulty,
score: this.score,
diffHex: this.diffHex,
submissions: []
};Je suis pas sur qu’il te file une plage en fait. Ca doit être fait un peu au pif. Par contre il te file une difficulté minimum à atteindre. En gros, tu lui file X share avec une diff Y en 1 secondes, il en déduis ta puissance de hash. Et le pool ajuste la diff pour éviter d’engorger le reseau. En gros de ton coté tu fait X MHS mais avec la diff, tu va filer seulement quelques share de diff Y par minutes pour prouver que tu bosses.
-
@raoullevert Sincèrement ta répondu à ma question exactement comme je le voulais, j’étais à deux doigts de te demander comment il détecté les mecs qui font semblant de miner mais ta répondu à ma question par télépatie
-
En fait le fait de le faire au hasard simplifie pas mal de chose. Si toutes les pools partaient à zéro et minaient exactement la même chose : aucun intérêt ! En fait c’est tout con de faire un pool BTC…
-
Merci à toi d’avoir soulevé la question. Je pensais avoir compris mais j’étais dans l’erreur.
-
@raoullevert Merci à toi surtout hehe, maintenant imagine qu’un mec trouve un block de la difficulté N demander par le réseaux BTC suite au dernier block, il pourrait alors arrêter de send c’est block et le proposé au réseaux btc directement et ce faire le pactole non?
-
La probabilité de trouver un block est tellement faible que ce serait une stratégie douteuse. Mais pourquoi pas. Après il faudrait que le mec se code un proxy stratum pour intercepter ‘LE’ share et le proposer sur le réseau.
C’est une attaque connue sous le nom de withholding attaque.
https://bitcointalk.org/index.php?topic=653617.0 -
Visiblement il n’y a pas de solution simple. A part envoyer de temps en temps un travail vraiment facile pour voir si le mineur réponds (ou pas). Ou lui envoyer un travail que tu sais forcement gagnant (déjà miné), ce qui est bien plus dur à détecter…
Après le protocole BTC n’implémente visiblement pas de solution directe. -
Donc petit rappel mémo technique, tu va me dire si c’est sa:
share = Block compute avec un nonce qui respecte une difficulté minimum donner par la pool
La pool règle le miner pour qu’il mine avec des shares à difficulté acceptable par rapport à sa puissance?
Le share permet juste de s’assuré que le gars mine?
La pool pour validé un block entier vérifie chaque share pour voir si il réspect la difficulté minimum(recevoir fee) et si le share est égale à la difficulté demander par le réseaux BTC? -
c’est exactement ça.
-
@raoullevert Donc ont peu jamais savoir sur le réseaux qui va faire sortir ce fameux block alors ont peu dire que c’est chaotic :d
-
et la difficulté donnée par le pool doit être un compromis entre débit et temps. Si un mec mets une heure à valider un share, au final il partagera rien : le bloc change toutes les 20 minutes. Avec un diff trop basse, ca consomme trop de débit.
-
@raoullevert ouep la difficulté minimum c’est surtout pour ne pas ralentir le miner(quand il envoi), et pour ne pas flood la pool(quand ta 750miners c’est chaud)
-
Tout a fait.
Après le mineur tu vas pas le ralentir vraiment, a part si il a un réseau vraiment pourris. Le miner il cherche en interne, et rejette une grande partie des solutions (diff trop basse).
D’ailleurs si tu tentes de filer des shares avec une diff trop basse, ils ne sont pas comptabilisés.
Du coup la bande passante nécessaire pour miner est très faible. c’est quelques ko/s -
Ce qui pourrais être pas mal coder un petit server pool en nodejs avec express/koa + memcached, une pool vraiment en open avec le moins de code possible qu’elle reste simple mais fonctionnel à grande échelle, avec la possibilité à n’importe qu’elle gars qui créer sa propre cryptomonnaie basé sur le principe de PoW de modifier 1/2 fonctions et que tout le code reste fonctionnel.
