Qu'est-ce qu'un mining pool ?

Un mining pool Bitcoin est un coordinateur de travail de preuve de travail. Plusieurs opérateurs d'ASIC y soumettent leur puissance de calcul. Le pool assemble les candidats de bloc, répartit l'espace de recherche, et redistribue la récompense selon des règles publiées quand un bloc valide est trouvé. Rien n'est fusionné physiquement : vous pointez le mineur vers un serveur, généralement en Stratum, et vous recevez un flux de jobs.

Pourquoi le solo est rarement viable à petite échelle

Trouver un bloc Bitcoin est un processus aléatoire, chaque hash ayant une chance minuscule de battre la cible de difficulté du réseau. L'espérance de temps entre deux blocs pour un hashrate donné est proportionnelle à la difficulté divisée par ce hashrate.

Concrètement, un opérateur qui représente une fraction négligeable du hashrate mondial peut attendre des mois, des années, ou ne jamais voir un bloc sur la durée de vie utile de son ASIC. Le pool ne change pas l'espérance mathématique à long terme, aux frais et à la qualité de connexion près. Il change la variance : beaucoup de petits paiements réguliers plutôt qu'un gain rare et massif.

Comment le travail est partagé

Le pool construit un template de bloc, avec ses transactions, sa coinbase et sa version, puis le découpe en espaces de nonce et d'extra-nonce. Chaque mineur cherche dans une portion distincte, ce qui évite le travail dupliqué.

Quand un ASIC trouve un hash suffisamment difficile pour la cible de share du pool, plus facile à atteindre que la cible du réseau, il envoie un share. Ce share prouve que le travail a été fait. Si un share atteint également la cible du réseau, le pool diffuse le bloc.

Les shares servent donc de compteur de travail, et les schémas de paiement, FPPS, PPLNS, PPS ou leurs variantes, traduisent ces shares en satoshis. Les formules diffèrent d'un pool à l'autre : la page de payout du pool que vous utilisez fait foi.

Ce que le pool fait, et ce qu'il ne fait pas

Un pool assure cinq fonctions : la coordination via ses serveurs Stratum, l'authentification des workers et l'envoi des jobs ; la construction des blocs, avec sa politique de sélection des transactions ; la propagation rapide du bloc trouvé pour réduire le risque d'orphelin ; la comptabilité, avec l'agrégation des shares, les soldes et les seuils de paiement ; et l'infrastructure, points de présence, bascule et supervision.

Il ne gère en revanche ni le courant, ni le refroidissement, ni le firmware de vos machines. Une coupure côté pool arrête votre contribution effective alors que les ventilateurs tournent encore, ce qui explique une partie des écarts entre hashrate local et hashrate rémunéré.

Un pool ne garantit pas non plus un bloc, ni un profit. Le prix du bitcoin, votre tarif électrique, l'efficacité de votre ASIC et la difficulté du réseau décident seuls de la marge. Et il ne constitue pas une garde obligatoire de vos fonds : la plupart des pools paient vers une adresse que vous contrôlez, sous réserve d'un seuil minimal de paiement.

Pourquoi un petit hashrate rejoint un pool

Trois raisons dominent chez les opérateurs d'un ou de quelques ASIC.

Le lissage des revenus. Un flux régulier, quotidien ou presque selon le schéma et le seuil, permet de payer l'électricité au fil de l'eau et de suivre le coût réel par TH/s.

La trésorerie. Attendre un bloc entier en solo immobilise du capital et expose à un retarget de difficulté, à une panne ou à une revente forcée avant le premier paiement.

L'exploitation. Un pool mature fournit des URL de failover, des statistiques par worker et parfois une API. Cela ne remplace pas votre monitoring local, mais un worker silencieux se voit immédiatement côté pool.

Le coût de cette agrégation est une commission, détaillée dans l'article sur les frais de pool, et une forme de dépendance : les shares déjà soumises ne vous suivent généralement pas si vous changez de pool.

Cinq points à vérifier avant de connecter un ASIC

1. Le schéma de paiement et sa page de documentation, pour savoir comment vos shares deviennent des satoshis et à quelle fréquence.
2. Les frais annoncés, en distinguant la commission du pool des éventuels frais de transaction retenus sur les paiements.
3. Les serveurs géographiques disponibles, en retenant le point de présence le plus proche pour limiter la latence et les shares périmées.
4. Le protocole supporté, Stratum V1 ou V2, en vérifiant que votre firmware parle le même dialecte, faute de quoi la négociation échoue.
5. Les règles de nommage des workers et le seuil minimal de paiement, qui déterminent quand vous toucherez réellement quelque chose.

Configurez toujours au moins un pool de secours. Et surveillez le taux de shares périmées ou rejetées dès les premiers jours : un chiffre élevé désigne la latence, une mauvaise URL ou un réglage de firmware, jamais la malchance seule.

Pour un hashrate petit face au réseau, le pool est l'outil par défaut. Pour un très gros parc, l'arbitrage entre solo et pool redevient une question de variance supportable, de contrôle du template et de trésorerie.