Jobs Stratum et clean_jobs

Un mineur passe son temps à hasher un travail que le pool peut invalider à tout moment. Comprendre ce mécanisme explique pourquoi des shares parfaitement calculées finissent en stale, et où agir pour en perdre moins.

Ce qu'est un job Stratum

Stratum est le protocole usuel entre le contrôleur de la machine et le serveur de pool. Le serveur envoie un job, c'est-à-dire les pièces d'un template de bloc : version, hash du bloc précédent, parties du coinbase, branches de Merkle, nBits, nTime, extra-nonce. Le firmware assemble un en-tête de 80 octets, fait tourner le nonce puis l'extra-nonce, et soumet toute preuve qui bat la cible de share.

Le job n'est pas le bloc. C'est une invitation à chercher dans un espace précis. Tant que le job est courant, les hashes comptent. Dès qu'il cesse de l'être, hasher dessus produit du travail mort, étiqueté stale ou rejected selon le pool.

Clean job : abandonner le travail en cours

Certains messages portent un drapeau clean_jobs, ou son équivalent selon la version du protocole. Il signifie une seule chose : abandonner immédiatement les jobs précédents. Le template a changé d'une façon qui invalide l'espace de recherche déjà ouvert, typiquement un nouveau bloc avec un nouveau prevhash, parfois un template reconstruit.

Sans ce drapeau, le pool peut ajouter du travail tout en continuant d'accepter les anciens jobs. Avec lui, la machine doit basculer. Un firmware qui ignore le drapeau, ou qui vide trop lentement sa file d'attente, continue de soumettre sur un état du réseau qui n'existe plus.

Ce comportement ne se règle pas depuis votre salle : il dépend de la politique du pool et de l'agent embarqué. Ce que vous pouvez constater, en revanche, c'est qu'après un bloc, toutes les machines d'un même VLAN reçoivent le nouveau job et arrêtent l'ancien dans la même seconde.

Les cinq causes d'invalidation

• Nouveau bloc sur le réseau. Le prevhash change, et tout job bâti sur l'ancien parent est mort.
• Nouveau template côté pool. Le pool reconstruit son candidat avec d'autres frais, d'autres transactions ou un autre extra-nonce. Même hauteur, autre racine de Merkle, donc autre contrat.
• Changement de difficulté de share. Le compteur du pool bouge, et hasher contre l'ancienne cible produit des shares hors contrat.
• Bascule de serveur ou failover. Un autre serveur stratum utilise d'autres identifiants de job. Soumettre un ancien identifiant vers le nouveau socket génère un rejet d'identité, sans rapport avec l'état des hashboards.
• Latence du chemin réseau. Plus le délai pour recevoir le nouveau job et abandonner l'ancien est long, plus la fraction de temps passée hors template augmente. VPN, Wi-Fi, NAT saturé, peering lointain ou CPU de contrôleur surchargé agissent tous sur ce délai.

L'arrivée des blocs reste un processus aléatoire : un clean peut tomber quelques secondes après le précédent. Une série de stales rapprochés n'indique donc pas nécessairement une anomalie.

Ce que vous contrôlez réellement

L'arrivée des blocs et la politique du pool vous échappent. Quatre leviers vous appartiennent :

• Le point de présence. Vérifiez l'URL stratum réellement utilisée par les machines, et choisissez le point de présence géographiquement le plus proche parmi ceux que propose le pool.
• La qualité du lien. Un câble pour le plan de contrôle, en évitant le Wi-Fi et le CPL, qui ajoutent une variance de latence que rien ne compense ensuite.
• Un failover à la fois. Deux agents qui minent le même worker en parallèle produisent des duplicatas et des rejets d'identité.
• L'application effective du nouveau job. Le job id et la hauteur sont visibles dans l'interface ou les logs du miner : après un bloc, ils doivent changer.

Comparez toujours vos machines sur la même fenêtre et le même pool. Si une seule unité reste collée à un ancien job id alors que ses voisines ont basculé, le problème vient de cette unité ou de son segment réseau.

Retenir un job mort plus longtemps n'améliore aucun comptage : les shares soumises dessus sont refusées, quelle que soit leur qualité. Le seul gain disponible se trouve dans le délai de bascule, donc dans le chemin réseau et dans le firmware.