Stale Rate désigne la proportion de résultats ou de travail pondéré considérés comme dépassés. Dans le minage de Bitcoin en pool, il s’agit généralement de shares : des preuves partielles de calcul qui ne correspondent plus à la tâche en cours. La définition précise et l’effet sur la rémunération dépendent du système observé.
Un pool est un service qui répartit le travail entre mineurs. Lorsque le réseau trouve un nouveau bloc, ils doivent généralement commencer à construire dessus. Un résultat calculé selon la tâche précédente ne convient plus au nouveau travail. Stratum V2, protocole de communication des machines de minage, gère ce changement avec SetNewPrevHash : la machine commence à chercher un bloc qui prolonge le bloc nouvellement indiqué. Parmi les tâches déjà préparées, seule celle désignée par l’identifiant de tâche job_id reste valide. Petra vérifie donc la validité de la tâche, pas seulement l’heure d’envoi du résultat. [1]
Dans un exemple simple, Petra soumet 100 résultats de difficulté identique. Le pool en accepte 98, en rejette 1 comme stale et 1 pour une autre raison. Les résultats stale rejetés représentent 1% ; tous les rejets réunis, 2%. F2Pool appelle rejection rate la proportion de tous les résultats rejetés parmi les résultats soumis. Dans notre exemple, stale n’en est qu’une partie. Ces chiffres expliquent le calcul, sans fixer de seuil acceptable en exploitation ; une autre classification peut donner un autre sens au tableau de bord. [2]
La difficulté d’une share détermine le niveau d’exigence du résultat à soumettre. Braiins comptabilise un résultat de difficulté d comme d unités de travail de base. Imaginons une share stale de difficulté 1 et une share acceptée de difficulté 9. En comptant les soumissions, on obtient 50% ; en pondérant le travail, 10%. Aucun calcul n’est faux en soi, mais ils répondent à des questions différentes. Pour comparer, Petra emploie donc la même unité au numérateur et au dénominateur et vérifie que la convention de difficulté est identique. [3]
La documentation de F2Pool distingue la catégorie Staled, qui produit une rémunération, des stale shares rejetées, qui n’en produisent pas. Le libellé seul ne permet donc pas de savoir si Petra a perdu de l’argent. Cette politique ne peut pas être généralisée à tous les pools : les règles du service concerné et le décompte effectif font foi. Avant de comparer des prestataires, Petra identifie la catégorie des résultats. Elle peut ensuite seulement estimer leur effet sur ses revenus. [2]
En lisant un journal de fonctionnement, on peut oublier que Stratum V2 permet de confirmer plusieurs soumissions par un seul message SubmitShares.Success. Le champ new_submits_accepted_count indique leur nombre nouvellement confirmé, tandis que new_shares_sum additionne leurs difficultés. Compter les réponses du serveur ne revient donc pas à compter les shares acceptées. En cas de rejet, SubmitShares.Error contient sequence_number, l’identifiant de la soumission, et error_code, le motif de l’erreur. Sans cette distinction, Petra pourrait prendre chaque erreur pour du travail arrivé trop tard. [1]
L’annonce d’un nouveau bloc doit d’abord circuler entre les ordinateurs qui vérifient Bitcoin. BIP152 décrit Compact Block Relay, un transfert de blocs plus économe en données entre les nœuds du réseau P2P, c’est-à-dire des participants directement connectés. Moins de données peuvent réduire le délai de transmission. Cela concerne cependant la propagation des blocs, pas la comptabilisation des shares par un pool. La proportion de blocs restés hors de la chaîne principale ne mesure donc pas les résultats tardifs de la machine de Petra. [4]
Braiins propose des statistiques de travail sur différentes périodes : shares_5m (5 dernières minutes), shares_60m (60 dernières minutes) et shares_24h (24 dernières heures). Petra ne peut pas diviser les résultats tardifs d’un court intervalle par le travail d’une journée entière et comparer ce chiffre aux statistiques horaires d’une autre machine. Les deux parties du calcul doivent couvrir la même période et les mêmes appareils. Si aucune soumission n’a été observée, le rapport est indéfini ; ce n’est pas une perte mesurée de 0%. Un trou dans le suivi ou une réponse manquante ne prouve pas non plus, à lui seul, qu’un résultat était stale. [5]
Petra commence par les changements de tâche, les motifs de rejet et les conditions de connexion sur la même période. F2Pool associe les résultats stale aux conditions du réseau. D’autres rejets peuvent venir d’erreurs du firmware, le logiciel qui pilote la machine, ou d’un overclocking excessif : augmenter la fréquence de fonctionnement des puces pour tenter d’effectuer davantage de calculs. Braiins conseille ping, un test simple pour vérifier si le serveur répond aux requêtes réseau. Une réponse positive ne confirme ni le bon déroulement du minage ni le versement d’une récompense. Un pourcentage global plus bas ne prouve pas à lui seul que la cause a disparu. Il faut comprendre ce qui a changé et suivre l’erreur précise dans des conditions comparables. [2] [6]
Pour une vision complète, lisez aussi Mining Share, Share Difficulty, Mining Latency, Pool Fee, Bitcoin. Cette entrée est également citée par Stale Block, Mining Latency.