Pool de secours et failover : à quoi servent les deuxième et troisième emplacements de l'ASIC

Presque tous les firmwares d'ASIC proposent trois champs pour l'adresse du pool. En général, un seul est rempli. Le deuxième et le troisième restent vides ou dupliquent la même adresse, ce qui les rend inutiles. C'est l'assurance la moins chère du minage : la configuration prend cinq minutes, ne coûte rien, et évite un arrêt lorsque le pool principal tombe.

Ci-dessous, on décortique le mécanisme de bascule, on calcule le coût de l'arrêt avec notre formule, et on traite à part un point que presque personne n'explique : ce qui arrive à votre contribution PPLNS quand le mineur passe sur le secours.

Que sont les trois emplacements de pool dans l'ASIC

Les trois emplacements forment une liste de priorité. Le mineur maintient une connexion stratum avec la première adresse. Si la connexion se coupe ou que le pool cesse de distribuer des tâches, le firmware essaie la deuxième adresse, puis la troisième. Rien de plus intelligent que ça : c'est un parcours séquentiel de haut en bas, sans répartition de charge et sans partage du hashrate entre pools.

Un point clé à comprendre sur la bascule : elle n'est pas instantanée. Le mineur doit d'abord déterminer qu'il n'y a vraiment plus de connexion. Il attend l'expiration d'un délai, tente parfois plusieurs reconnexions sur la première adresse, et ne passe à la suivante qu'ensuite. La durée de cette fenêtre dépend du firmware et de la version, il n'y a pas de norme unique. Consultez la valeur exacte dans l'interface web de votre appareil, dans les paramètres du pool, ou dans les journaux : on y voit au bout de combien de secondes après la coupure le mineur a commencé à solliciter la deuxième adresse.

On en tire une conclusion pratique. Le failover ne protège pas contre des coupures courtes de quelques secondes. Il protège contre des situations qui durent des minutes voire des heures : le pool est tombé, il a des problèmes de DNS, votre fournisseur a perdu la route vers un data center précis. Comment distinguer un problème côté pool d'un problème côté chez vous est détaillé dans l'article le pool est en panne : diagnostic pas à pas.

Deuxième point : la plupart des firmwares reviennent automatiquement au premier pool une fois qu'il est rétabli. Autrement dit, le secours fonctionne comme une plateforme temporaire, pas comme un déménagement. Mais ce comportement doit être vérifié séparément sur votre propre modèle, car il dépend aussi du firmware.

Combien coûte une heure d'arrêt

On part de la formule de base de la production attendue. Revenu sur une période à hashrate donné :

```

BTC = H * 86400 * R / (D * 2^32)

```

où H est le hashrate en hashs par seconde, 86400 le nombre de secondes dans une journée, R la récompense de bloc en BTC, D la difficulté du réseau. La formule donne une espérance mathématique, pas une garantie : sur de petits volumes, la production réelle oscille autour de ce chiffre.

On applique au réseau au 08.09.2026 : difficulté de 127,45 billions, récompense de 3,125 BTC, hashrate réseau de 930,73 EH/s, part des frais dans le bloc de 0,66 pour cent. Avec ces paramètres, 100 TH/s produisent 0,00004932 BTC par jour. Au cours de 78 349 dollars, cela fait 3,86 dollars par jour, soit 16,1 cents par heure.

Ensuite, une simple règle de trois selon l'échelle :

Sur un S21 domestique, la différence entre 1 et 5 pour cent d'arrêt par mois se mesure en quelques dollars, et à ce niveau le failover relève plus de l'hygiène que de l'argent. À dix pétahash, les mêmes pourcentages se transforment en centaines de dollars par mois, et configurer le deuxième emplacement se rentabilise dès la première panne. Vous pouvez tester vos propres chiffres via le calculateur de rentabilité, en indiquant votre hashrate et le prix de l'électricité.

Il faut aussi se rappeler que l'arrêt n'est pas gratuit côté dépenses : le matériel en panne côté pool continue de consommer de l'électricité si le mineur tourne à vide en tentant de se reconnecter.

Ce qui arrive à la contribution PPLNS lors du passage sur le secours

Réponse directe : en PPLNS, vos shares déjà envoyés ne sont pas annulés au moment de la déconnexion. Ils restent dans la fenêtre et continuent à participer au partage des blocs que le pool trouvera prochainement, puis sont progressivement évincés par les nouveaux shares d'autres mineurs. Un passage court sur le secours coûte nettement moins cher qu'on ne le pense généralement. Un passage long dévore la contribution entièrement.

Voici le mécanisme. Le PPLNS ne paie pas pour le share en lui-même, mais pour la part de vos shares parmi les N derniers shares du pool au moment où un bloc est trouvé. Tant que vos shares sont dans cette fenêtre, chaque bloc trouvé vous rapporte une part de la récompense. Dès que le flux de shares d'autrui évince les vôtres hors de la fenêtre, ils cessent d'être pris en compte. Ce n'est ni une pénalité ni une perte, c'est un simple glissement naturel de la fenêtre.

La taille de la fenêtre varie selon les pools, et sa formulation aussi. D'après notre analyse de la documentation :

D'où une règle pratique : plus la fenêtre du pool principal est large, plus on peut traverser sereinement des passages courts sur le secours. Chez Ocean, une fenêtre de huit difficultés réseau signifie qu'un share arrive en moyenne à participer au partage plusieurs fois, et une coupure de dix minutes ne fait presque rien perdre. Avec une fenêtre courte, la même coupure coûte plus cher.

Et inversement : un passage sur le secours de plusieurs heures signifie qu'au moment du retour, il ne reste presque plus rien de votre contribution dans la fenêtre du pool principal, et l'accumulation recommence de zéro. C'est pourquoi les pannes longues sont plus douloureuses en PPLNS qu'en PPS et FPPS, où le paiement ne dépend pas du fait que le pool ait trouvé un bloc ou non.

Remarque importante : la plupart des grands pools BTC fonctionnent par défaut non pas en PPLNS mais en FPPS ou PPS+. Si vous êtes en FPPS, toute cette arithmétique de fenêtre ne vous concerne pas, et le passage sur le secours coûte exactement ce que vous n'avez pas miné pendant l'arrêt, ni plus ni moins.

Comment choisir un pool de secours

Réponse directe : prenez un secours avec le même schéma de paiement que le pool principal, mais n'essayez pas de trouver un pool de la même taille. La correspondance du schéma est importante, car elle détermine comment se calcule le revenu pendant l'arrêt et si vous devrez démêler deux modèles de paiement différents en une semaine. La taille du pool n'y change rien.

Pourquoi le schéma compte plus que la taille. Si le pool principal est en FPPS et le secours en PPLNS, chaque bascule fait repartir l'accumulation de contribution de zéro dans une fenêtre étrangère, et au retour cette contribution reste sous-exploitée. En plus, la vérification des rapports est plus compliquée : sur FPPS le revenu est régulier, sur PPLNS il est lié aux découvertes de blocs. Un schéma identique rend les deux plateformes comparables.

Pourquoi la taille n'est pas critique. Le hashrate du pool influence la variance des paiements : un petit pool trouve les blocs moins souvent, donc le revenu est plus irrégulier. Mais le secours, par définition, fonctionne par courts épisodes. Sur deux heures d'arrêt, la variance d'un petit pool ne vous coûtera rien, parce qu'en FPPS elle n'existe pas du tout, et qu'en PPLNS la contribution sur quelques heures reste de toute façon modeste.

Ce sur quoi il faut vraiment se pencher pour choisir un secours :

1. Le schéma de paiement correspond à celui du pool principal.
2. Le seuil de paiement est atteignable. C'est le principal piège, détaillé plus bas.
3. La géographie des serveurs diffère de celle du pool principal. Un secours dans le même data center que le principal ne sauve pas d'une panne du data center.
4. L'inscription n'exige pas une procédure KYC d'une semaine, sinon le secours ne pourra pas être mis en place rapidement.
5. Les frais et seuils sont connus à l'avance. On peut les comparer par pool dans nos analyses des frais et des paiements minimums.

Sur la question de savoir si changer de pool en vaut la peine, et pourquoi des déménagements fréquents ne sont pas gratuits, une analyse séparée existe : le coût du changement de pool.

Faut-il mettre un solo ou un autre pool en troisième emplacement

Réponse directe : le troisième emplacement a du sens s'il n'est pas une copie du deuxième, mais une assurance contre un autre type de panne. Le deuxième emplacement couvre la chute d'un pool précis. Le troisième doit couvrir la situation où les deux sont inaccessibles, par exemple à cause d'un problème de route vers une région ou d'un blocage côté fournisseur.

Options raisonnables pour le troisième emplacement :

1. Un pool d'une autre juridiction, avec une autre infrastructure réseau. Le choix le plus pratique pour la plupart.
2. Un pool solo. Cela a du sens si vous êtes prêt, par principe, à un revenu nul la plupart du temps pour la chance de loterie de trouver un bloc. Comme régime permanent pour un petit hashrate, c'est un pari assumé, pas un calcul. Comme troisième emplacement qui s'active pendant les rares heures de panne, le solo coûte à peu près le prix de ces heures d'arrêt du tableau ci-dessus.
3. Le même pool, mais une autre adresse de son point d'accès stratum dans une autre région. Cela protège d'une panne régionale, mais pas d'une panne du pool entier.

Beaucoup utilisent l'option 3 comme deuxième emplacement, et ce n'est pas mal. Mais dans ce cas, le troisième emplacement doit obligatoirement être un pool tiers, sinon toute la liste dépend d'un seul opérateur.

Erreurs typiques dans la configuration du failover

1. La même adresse dans les trois emplacements. Le cas le plus fréquent. La liste paraît remplie, mais il n'y a aucune protection : le pool tombe, les trois entrées tombent.
2. Un secours avec un worker non vérifié. Le login a été saisi de mémoire, avec une faute de frappe ou pour un sous-compte inexistant. Tant que le pool principal est vivant, l'erreur ne se voit pas. Au moment de la panne, le mineur bascule et reçoit un refus d'autorisation.
3. Un seuil de paiement que vous n'atteindrez jamais. Si le secours paie à partir d'une somme que votre hashrate accumulera en des années de pannes rares, l'argent s'entasse simplement sur le solde. Chez certains pools, le reliquat sous le seuil ne disparaît pas et attend le cycle suivant, mais chez d'autres, il existe des règles sur les comptes inactifs et les adresses de paiement non renseignées, pouvant aller jusqu'à la perte des droits sur l'accumulé selon les conditions de service. Lisez les conditions du pool concerné avant d'en faire un secours.
4. Le failover est configuré mais jamais testé. La catégorie la plus regrettable, car la personne est persuadée d'être protégée.
5. Un secours avec la même adresse de paiement et le même e-mail que le principal, sans vérification d'accès séparée. Si vous perdez l'accès au compte au moment de la panne, l'emplacement configuré ne sert pas à grand-chose.
6. Un secours ajouté seulement sur une partie des équipements. Dans une ferme de trente ASIC, une configuration via un modèle de configuration garantit l'uniformité ; un parcours manuel appareil par appareil laisse presque toujours des oublis.

Comment vérifier que le failover fonctionne

Réponse directe : il faut vérifier par une coupure forcée de la connexion au pool principal, pas en théorie. La méthode la plus sûre consiste à changer temporairement l'ordre des emplacements ou à bloquer l'adresse du pool principal sur le routeur, à observer que le mineur est passé sur la deuxième adresse et a commencé à soumettre des shares acceptés, puis à tout remettre comme avant.

Ordre des actions :

1. Assurez-vous que le worker sur le pool de secours est créé et visible dans son tableau de bord. Le plus simple est de diriger un mineur vers le secours pendant dix minutes et de voir apparaître du hashrate sur ce worker.
2. Notez l'état actuel : adresses dans les trois emplacements, noms des workers, hashrate actuel sur le pool principal.
3. Bloquez l'accès au pool principal. Options : une règle sur le routeur par domaine ou par IP, la désactivation d'un port précis, ou le remplacement temporaire de l'adresse du premier emplacement par une adresse manifestement non fonctionnelle.
4. Chronométrez. Notez au bout de combien de secondes le mineur est passé sur la deuxième adresse. C'est votre délai réel de failover, et c'est cette valeur qu'il faut garder en tête en estimant les pertes.
5. Vérifiez dans le tableau de bord du pool de secours que les shares du worker arrivent et sont reconnus comme valides. La simple présence d'une connexion ne suffit pas.
6. Levez le blocage et regardez si le mineur revient de lui-même sur le premier emplacement. Si non, le retour est manuel, et il faut en tenir compte dans la procédure.
7. Répétez la même chose pour le troisième emplacement, en bloquant à la fois le premier et le deuxième pool.
8. Notez les résultats et la date de la vérification. Répétez après chaque mise à jour de firmware : le comportement du failover change d'une version à l'autre.

Il est pratique de combiner la vérification avec des travaux planifiés, quand une partie du hashrate est de toute façon à l'arrêt. Le coût de la vérification elle-même se calcule avec le même tableau : dix minutes à 10 PH/s font environ 2,7 dollars, une dépense unique pour la certitude que la protection fonctionne.

En bref

Trois emplacements au lieu d'un n'augmentent pas le revenu. Ils suppriment du graphique les creux qui, sinon, se prolongent jusqu'à ce que vous remarquiez le problème vous-même. Avec un petit hashrate, le gain se mesure en quelques dollars par mois ; avec un hashrate industriel, en centaines et en milliers.

Trois choses sont utiles à retenir. La bascule n'est pas instantanée, elle suit le délai du firmware, et il faut mesurer sa valeur chez soi. En PPLNS, un passage court sur le secours coûte moins cher qu'il n'y paraît, car les shares vieillissent progressivement dans la fenêtre au lieu d'être annulés. Et un failover configuré mais jamais testé n'est pas une protection, c'est son imitation.

Pour estimer ce que coûte l'arrêt sur votre configuration précise, utilisez le calculateur, et pour comparer les conditions des pools pour le secours, consultez la section comparaison des pools.