Mining Pool

Anna possède une machine de minage. Elle paie de l'électricité chaque jour, mais en minant seule, elle pourrait attendre très longtemps avant de trouver un bloc. Si elle en trouve un que le réseau accepte, elle en reçoit toute la récompense ; jusque-là, ce minage ne lui rapporte rien. Avoir attendu longtemps ne signifie pas non plus que la réussite approche. À conditions identiques, chaque nouvelle tentative conserve la même probabilité. Dans un pool, sa machine travaille avec d'autres. Le pool peut rémunérer un mineur qui n'a pas trouvé un bloc donné, car il mesure les contributions et applique un modèle de rémunération convenu. Anna renonce à conserver tout le revenu de son propre bloc en échange de sommes plus petites et généralement plus régulières. Cela ne réduit pas la difficulté du réseau et ne crée pas de récompenses supplémentaires. Le pool prélève aussi habituellement des frais. Savoir si les revenus couvrent l'électricité et le matériel est une autre question. [6] [7]

Le pool ne voit pas chaque calcul de la machine d'Anna. Il doit pourtant vérifier qu'elle travaille et estimer sa contribution. Il fixe donc une condition plus facile que celle du réseau Bitcoin. Un résultat qui la remplit s'appelle un Mining Share, ou share. La machine peut ainsi fournir régulièrement des résultats vérifiables sans avoir trouvé de bloc. Le pool estime statistiquement le travail à partir des shares acceptés et de leur difficulté. Ce n'est pas un compteur exact de toutes les tentatives. Si deux machines ont des difficultés de share différentes, leurs nombres de résultats ne sont pas directement comparables. Un share ordinaire ne crée ni bloc Bitcoin ni confirmation de paiement. Seul un résultat rare qui satisfait aussi la condition du réseau permet de soumettre un bloc, lequel doit encore passer les autres vérifications. Un share atteste donc d'un travail pour le pool ; ce n'est pas un morceau de bitcoin que la machine vient de fabriquer. [7] [9]

Anna peut connecter la même machine à plusieurs pools et observer des revenus différents. Le modèle de calcul en est une raison. PPS, pour Pay Per Share, crédite chaque share accepté d'une valeur attendue fixée à l'avance en fonction de sa difficulté. Anna n'attend pas que son pool ait la chance de trouver un bloc : l'opérateur assume le risque des variations aléatoires des découvertes. Cela ne garantit ni sa capacité à toujours payer ni un salaire horaire fixe. Le nombre de shares et les conditions de minage continuent de varier. FPPS, Full Pay Per Share, ajoute généralement une estimation des frais de transaction à la part attendue des bitcoins nouvellement émis. PPLNS, Pay Per Last N Shares, répartit au contraire les revenus des blocs réellement trouvés selon le travail d'une fenêtre récente définie. Les récompenses dépendent davantage de la chance du pool. Ses règles définissent cette fenêtre ; elle ne correspond pas forcément à la dernière heure. Le sigle ne suffit pas pour comparer. Les frais, la méthode d'estimation, la taille de la fenêtre et le traitement des blocs hors de l'historique principal, les Stale Blocks, comptent aussi. Le modèle détermine les droits et le calcul des récompenses ; leur calendrier de transfert vers le portefeuille relève d'une autre règle. [7] [8]

Anna voit augmenter le solde de son compte. Tant qu'il n'est pas arrivé dans son portefeuille, elle compte sur le pool pour bien le comptabiliser et le verser. Elle doit connaître la date de paiement, le seuil éventuel, les frais et l'adresse de destination. Les services diffèrent : créditer automatiquement une récompense ne signifie pas la transférer immédiatement. Il faut aussi suivre le fonctionnement : shares acceptés ou rejetés, leur difficulté appelée Share Difficulty, disponibilité des serveurs et connexions de secours. Le firmware est le logiciel qui commande le mineur ; il doit fonctionner avec le pool. Comparer les relevés du pool sur une période assez longue avec ses propres journaux d'activité et les paiements reçus aide à repérer des écarts. Les blocs trouvés sont vérifiables sur la blockchain, mais celle-ci ne révèle pas toute la comptabilité interne du pool. Pouvoir changer de pool et savoir qui choisit les transactions compte également. [8] [9]

Si la tâche change avant l'arrivée du résultat, le pool peut ne plus le comptabiliser. La latence désigne ici le délai de communication entre l'appareil et le pool. Un share peut être rejeté parce qu’il est périmé (stale), dupliqué, mal construit ou incompatible avec la tâche attribuée. Une latence plus élevée entre le mineur et le pool, des mises à jour lentes des tâches et des interruptions du réseau augmentent le travail perdu. La proportion de stale shares renseigne donc sur l’efficacité opérationnelle de la liaison entre le mineur et le pool ; ce n’est pas la même chose qu’un Stale Block dans la blockchain. [9]

La récompense du bloc est inscrite dans une première transaction particulière, la Coinbase Transaction. Ses sorties précisent les montants et les conditions permettant de les dépenser plus tard. La récompense peut donc aller à un ou plusieurs destinataires. Un Block Template est le projet de bloc avec les transactions sélectionnées. Dans un pool classique, l’opérateur du pool prépare généralement le Block Template et détermine aussi le destinataire de la sortie coinbase. Le mineur essaie surtout différentes valeurs dans la tâche qui lui est attribuée, à la recherche d’un résultat satisfaisant la condition du réseau. Le pool acquiert ainsi une influence sur la sélection des transactions, mais pas la capacité d’imposer un bloc invalide ; chaque Full Node vérifie le bloc indépendamment. Un Full Node est un logiciel qui vérifie les blocs et les transactions selon les règles de Bitcoin. [6] [10]

Au-delà du montant versé, il importe de savoir qui décide quels paiements entrent dans les blocs. Écarter certaines transactions peut retarder leur confirmation. La concentration des pools importe, car un petit nombre de coordinateurs peut influencer l’inclusion des transactions, le déploiement des logiciels et la répartition du Hashrate à court terme. Le Hashrate est le nombre de calculs de minage effectués par seconde. Le Hashrate d’un pool n’est toutefois pas équivalent à la propriété des équipements de minage : les exploitants de machines spécialisées dans le minage, appelées ASIC, peuvent les connecter à un autre pool. Le risque augmente si les coûts de changement de pool, les contrats ou le micrologiciel limitent cette possibilité. [6] [10]

Stratum définit les échanges entre mineur et pool. Le chiffrement protège les messages transmis, tandis que l'authentification aide à vérifier l'identité de l'autre partie. Stratum V1 sert à attribuer le travail de minage, et le contrôle du modèle reste généralement au pool. Stratum V2 distingue plus clairement les rôles et prend en charge des communications chiffrées et authentifiées. Le Job Declaration Protocol optionnel permet au mineur de soumettre son propre modèle avec sa propre sélection de transactions, si le mineur et le pool prennent tous deux en charge les composants nécessaires. Le Mining Protocol de Stratum V2 peut fonctionner seul, sans cette possibilité ; la désignation Stratum V2 ne garantit donc pas à elle seule une sélection indépendante des transactions. [10]

Pour comprendre la mécanique : un Block Template est une proposition de contenu pour un bloc. Worker désigne un appareil connecté ou le compte auquel son travail est rattaché ; l'en-tête résume les informations essentielles du bloc. Une tâche de minage repose sur un Block Template ou une construction équivalente d’un bloc candidat. BIP22 décrit getblocktemplate et BIP23 ses extensions pour le minage en pool. Le protocole du pool transmet aux workers les champs nécessaires, les données de la transaction coinbase et l’espace de recherche. Un ASIC Miner essaie différents en-têtes et calcule leur hash, une empreinte numérique. Pour satisfaire Proof of Work, la preuve du travail de calcul, ce hash doit être inférieur ou égal au seuil du réseau, appelé target. Le bloc doit aussi respecter les autres règles de Bitcoin. [1] [2] [5]

Détail technique : le target est un seuil numérique que le hash, résultat du calcul de minage, ne doit pas dépasser ; l'égalité convient aussi. VarDiff désigne une difficulté variable des shares. Le pool définit un share target plus facile pour recevoir des résultats assez souvent pour effectuer ses mesures. Le target du réseau Bitcoin est bien plus difficile à satisfaire. Un share accepté qui satisfait uniquement le target du pool est comptabilisé selon les règles de rémunération du pool ; si le même hash satisfait aussi le target du réseau, un bloc candidat peut être soumis. VarDiff modifie la difficulté des shares et donc leur fréquence, pas la Difficulty de consensus de Bitcoin. [9]