Meilleur Share Solo, Pas de Bloc : eCash RTT

Le Real-Time Targeting d’eCash, connu sous le nom de Heartbeat, est une règle de consensus qui relève la cible de minage exigée pendant environ deux minutes après chaque bloc, puis la laisse décroître jusqu’à la difficulté publiée. Un share qui bat la difficulté affichée sur un explorateur n’est un bloc valide que s’il arrive après cette décroissance. C’est de loin la raison la plus fréquente pour laquelle un mineur solo sur XEC voit un share record et ne gagne rien.

Points clés à retenir

• eCash exige une difficulté supérieure à celle publiée pendant environ 115 secondes après chaque bloc, à cadence stable.
• L’exigence démarre astronomiquement haut et chute comme la puissance cinquième du temps écoulé. Elle ne peut jamais être plus facile que la difficulté standard.
• Les explorateurs affichent la difficulté de chaque bloc tel qu’il a été miné — la valeur plancher. Il n’existe aucun flux public de l’exigence en direct.
• Nous avons reproduit la formule officielle sur les logs d’un nœud en production, à travers 15 mesures : écart maximal de 0,002%.
• La rampe initiale abrupte que rencontrent les mineurs solo aujourd’hui existe entièrement à cause de la mise à jour du 15 novembre 2025, qui a ajouté une fenêtre de filtre d’un bloc.

Pourquoi mon share a-t-il battu la difficulté réseau sans trouver de bloc ?

Un mineur nous a écrit avec une plainte précise et parfaitement légitime. Il avait résolu un bloc eCash avec un share d’environ 8,0 milliards de difficulté face à une difficulté réseau publiée d’environ 7,36 milliards. Des heures plus tard, son mineur a enregistré un share bien meilleur — environ 11,87 milliards — et rien ne s’est passé. Il a vérifié chaque bloc de la chaîne depuis. La difficulté publiée était restée entre 7,1 et 7,4 milliards toute la nuit. Selon les règles de Bitcoin, ce share était un bloc.

Il avait raison sur les chiffres et tort sur la règle. Sur eCash, la difficulté que publie un explorateur n’est pas la difficulté à battre au moment où vous soumettez. C’est le plancher.

Son share de 11,87 milliards est arrivé environ 100 secondes après le bloc précédent — encore dans la rampe. À cet instant le réseau exigeait 14,85 milliards, le share valait donc environ 80% de ce qu’il fallait. Quinze secondes plus tard la rampe était retombée, l’exigence est descendue à 7,33 milliards, et ce même share aurait gagné. Il ne manquait pas de hashrate. Il lui manquait un quart de minute.

Qu’est-ce que le Real-Time Targeting d’eCash ?

Le Real-Time Targeting a été activé avec la mise à jour Heartbeat le 15 novembre 2024. Le problème qu’il résout est propre aux chaînes SHA-256 minoritaires.

eCash partage son algorithme avec Bitcoin et Bitcoin Cash, si bien que le hashrate circule entre elles en quête de rentabilité. Quand la difficulté d’eCash baisse, du hashrate extérieur afflue et mine plusieurs blocs coup sur coup — les blocs turbo. L’algorithme de difficulté standard réagit en relevant la difficulté ; le hashrate de passage repart ; la chaîne se retrouve échouée avec une difficulté élevée et une fraction du hashrate, produisant des trous entre blocs pouvant durer des heures. Les dépôts se bloquent. Les confirmations deviennent imprévisibles.

Heartbeat s’attaque à la première moitié de ce cycle. En rendant invalides les blocs minés trop tôt après leur prédécesseur, il supprime la récompense du minage en rafale, si bien que l’algorithme de base ne surcorrige jamais. La conception s’inspire des travaux de Tom Harding sur le Real-Time Block Rate Targeting.

Le mécanisme ne fonctionne que grâce à Avalanche. Le ciblage en temps réel dépend de la mesure propre à chaque nœud du moment où un bloc est arrivé, ce qui est intrinsèquement subjectif. Le post-consensus Avalanche réconcilie ces vues subjectives en une décision réseau unique, sans toucher à l’en-tête du bloc ni au consensus Nakamoto.

Comment la cible en temps réel d’eCash est-elle calculée ?

La règle est implémentée dans Bitcoin ABC comme une politique de garage plutôt que comme une règle de validité. Le code source concerné se trouve dans src/policy/block/rtt.cpp, et la formule centrale est énoncée dans le commentaire du fichier lui-même :

target(t) = target(prev_block) * RTT_CONSTANT_FACTOR * t^(RTT_K - 1)

RTT_CONSTANT_FACTOR = RTT_K * gamma(1 + 1/RTT_K)^RTT_K / T^(RTT_K - 1)

RTT_K vaut 6, la cible évolue donc avec la puissance cinquième du temps écoulé. T est l’espacement cible pour cette fenêtre de filtre. Le temps écoulé est mesuré à partir du moment où le nœud a reçu chaque en-tête de bloc précédent, et non depuis l’horodatage inscrit dans l’en-tête.

La formule est évaluée sur cinq fenêtres simultanément, et le résultat le plus strict l’emporte :

Les longueurs de fenêtre sont des nombres premiers, avec un saut entre chaque entrée successive. Le code source explique pourquoi : c’est une tentative appliquée d’éviter les fréquences de résonance lors du chaînage d’une série de filtres. La série s’arrête à 17 blocs parce que des fenêtres supplémentaires ne modifient plus la sélectivité du filtre de manière significative.

Deux propriétés comptent pour les mineurs. C’est la cible la plus basse parmi toutes les fenêtres qui s’applique, donc c’est la contrainte la plus dure qui gouverne. Et le résultat est plafonné : la cible en temps réel n’est jamais plus haute — jamais plus facile — que la cible standard. La difficulté ne peut être poussée que vers le haut, jamais vers le bas.

Reconstruire les constantes à partir de gamma(1 + 1/6) = 0.9277193336 reproduit les cinq coefficients publiés à dix chiffres significatifs.

Combien un bloc eCash est-il plus dur juste après le précédent ?

Voici le tableau qui n’existe nulle part ailleurs, calculé à partir de la formule officielle à une cadence stable de dix minutes. Le multiplicateur s’applique à la difficulté qu’un explorateur publierait.

Un bloc trouvé une seconde après son prédécesseur nécessiterait environ vingt milliards de fois la difficulté publiée. À dix secondes, deux cent mille fois. La courbe est brutalement abrupte puis s’arrête simplement : après environ 115 secondes l’exigence égale exactement la difficulté publiée, et y reste.

Quand les blocs récents sont arrivés plus vite que dix minutes, chaque fenêtre part d’un temps écoulé plus court et la rampe démarre plus haut tout en durant plus longtemps. Ce n’est pas un effet de bord. C’est le mécanisme anti-blocs-turbo qui fait son travail.

La formule correspond-elle à ce que fait réellement un nœud ?

Nous l’avons testé. Ci-dessous les valeurs consignées par l’un de nos nœuds eCash dans les deux minutes et demie suivant un bloc, à côté des valeurs prédites par la formule publiée en n’utilisant que les temps d’arrivée de bloc visibles dans ce même log.

Sur les quinze mesures consignées, l’écart maximal était de 0,002%. La formule publiée n’est pas une approximation de ce que font les nœuds — c’est exactement ce qu’ils font.

Un détail mérite d’être relevé. Pendant les 99 premières secondes, la contrainte déterminante était la fenêtre d’un bloc. Ce n’est qu’à 109 secondes que la fenêtre de deux blocs a pris le relais, et 40 secondes plus tard la difficulté standard a fixé le plancher.

Qu’est-ce qui a changé le 15 novembre 2025 ?

Avant cette mise à jour il y avait quatre fenêtres, à partir de deux blocs. La mise à jour du 15 novembre 2025 a ajouté la fenêtre d’un bloc avec son espacement de 150 secondes.

Passer les deux configurations dans la formule à une cadence stable de dix minutes donne un résultat frappant :

À cadence normale, la configuration à quatre fenêtres ne produisait aucune rampe du tout. Elle ne s’enclenchait que lorsque les blocs arrivaient déjà trop vite — ce qui était son objectif restreint. La rampe initiale abrupte que rencontre aujourd’hui un mineur solo, sur une chaîne par ailleurs saine, existe entièrement à cause de la fenêtre d’un bloc ajoutée en novembre 2025.

Si vous avez miné eCash en solo avant cette date et n’avez jamais vu cela se produire, voilà pourquoi.

Pourquoi la difficulté affichée par mon pool ne correspond-elle pas à l’explorateur ?

Parce que sur eCash ce sont des nombres différents, et le logiciel de minage le dit.

Le logiciel de minage solo eCash de Bitcoin ABC lit rtt.nexttarget à chaque appel getblocktemplate, le convertit en difficulté et — pour eCash uniquement — utilise cette valeur comme difficulté réseau qu’il rapporte et consigne. Toute autre chaîne SHA-256 utilise à la place les bits de difficulté de l’en-tête de bloc.

Cette seule bifurcation explique le comportement que constate tout opérateur de pool eCash : après l’arrivée d’un bloc, la difficulté réseau rapportée est astronomiquement haute, chute d’un ordre de grandeur toutes les dix secondes pendant environ deux minutes, puis se stabilise à la valeur qu’un explorateur finira par publier.

Les opérateurs de nœud ont une seconde option : calculer la cible localement à partir de rtt.prevheadertime, rtt.prevbits et rtt.nodetime, tous présents dans le modèle de bloc. Les deux voies sont documentées sur la page minage d’eCash.

Qu’arrive-t-il à un bloc qui viole la cible en temps réel ?

Il est garé, pas rejeté. Le nœud le marque d’une violation de politique étiquetée policy-bad-rtt et le met de côté, puis le sondage Avalanche décide si le reste du réseau est d’accord. Si le nœud est minoritaire, il retourne sa position. L’en-tête du bloc reste intact tout du long, et le consensus Nakamoto n’est pas modifié.

Exécuter getchaintips sur un nœud eCash les montre à côté de la chaîne active, marqués status: parked. Sur l’un de nos nœuds, l’appel a renvoyé 262 têtes de branche garées couvrant les hauteurs de bloc 940 265 à 960 666 — environ 20 400 blocs, soit à peu près 1,3% des blocs de cette plage garés au moins une fois.

Ce chiffre est une borne supérieure des violations de la cible en temps réel, pas un décompte de celles-ci. eCash gare des blocs pour plusieurs raisons, et Avalanche gare aussi le camp perdant d’une course de fork ordinaire. Mais sur une chaîne où deux blocs concurrents à la même hauteur sont rares, un taux de têtes garées au-dessus d’un pour cent vous dit que le mécanisme est actif et travaille, pas qu’il reste inerte.

Cela s’applique-t-il à Bitcoin, Bitcoin Cash ou aux autres chaînes SHA-256 ?

Non. Parmi les chaînes SHA-256, ce comportement est propre à eCash, car il dépend de la couche Avalanche pour réconcilier une temporalité subjective.

Sur Bitcoin et Bitcoin Cash, un share au-dessus de la difficulté réseau est un bloc, point final. Si vous minez plusieurs chaînes et comparez vos chiffres de meilleur share entre elles, la colonne eCash est la seule où la temporalité entre dans le calcul. Notre décomposition des probabilités du minage solo et le Radar Réseau utilisent tous deux la difficulté publiée, qui est la bonne base pour la probabilité à long terme — la rampe se moyenne dans le temps.

Quelle est la taille de la zone morte pour un mineur solo ?

Tout share tombant avant que la rampe ne soit retombée est gaspillé, aussi bon soit-il. À cadence stable :

Environ un cinquième de chaque intervalle de bloc est inutilisable pour un share qui franchit tout juste la difficulté. Les shares plus forts franchissent la rampe plus tôt, ce qui explique qu’un share véritablement énorme n’est presque jamais gaspillé.

Cela ne change en rien votre rendement attendu d’une manière sur laquelle vous pourriez agir. C’est déjà reflété dans la production réelle de blocs de la chaîne, et donc dans la difficulté elle-même. Rien dans la configuration de votre mineur ne l’influence.

Que devrait réellement faire un mineur solo face à cela ?

Pour la plupart des gens, la réponse honnête est rien — mais lisez vos chiffres correctement.

• L’affichage de meilleure difficulté de votre mineur est calculé localement, à l’instant où le hash est trouvé, avant que le pool n’ait répondu. Il enregistre la valeur que le share ait été valide ou non. C’est aussi un chiffre historique qui ne se réinitialise pas quand vous trouvez un bloc.
• Un meilleur share historique au-dessus de la difficulté publiée sur eCash n’est pas la preuve d’un bloc manqué ou volé. Si vous voulez confirmer qu’un bloc existe, regardez la transaction coinbase on-chain. Sur un pool non dépositaire, votre adresse est inscrite dans le coinbase avant le début du hachage, donc un bloc réel est visible à votre propre nom et personne ne peut le déplacer.
• Si vous êtes curieux de savoir à quel point vous avez été proche, notre article meilleur share expliqué explique comment lire ces chiffres, et le calculateur de probabilités convertit le hashrate en attentes réalistes. La page du pool eCash liste la difficulté actuelle et tous les points d’accès régionaux, le générateur de configuration construit les réglages stratum, et les données en direct sur les blocs et les workers se trouvent sur le tableau de bord du pool.

Si vous faites tourner votre propre nœud eCash pour miner en solo, un élément de configuration compte. Un nœud a besoin de 17 blocs de temps d’arrivée d’en-tête enregistrés avant de pouvoir calculer la cible en temps réel. Tant qu’il ne les a pas, il peut construire des modèles à une difficulté trop basse et voir ses blocs garés. Régler persistrecentheaderstime=1 enregistre ces temps de référence sur disque et les recharge au redémarrage, ce qui comble le trou.

Sources

• Documentation minage d’eCash — les champs RTT du modèle de bloc, l’implémentation de référence du calcul de la cible et les coefficients de filtre publiés
• Heartbeat Upgrade: A Steady Pulse for eCash — la justification, le problème du minage opportuniste et le rôle du post-consensus Avalanche
• Code source de Bitcoin ABC — src/policy/block/rtt.cpp, contenant la formule, les constantes de fenêtre et la politique de garage
• Logiciel de minage solo eCash — comment la cible en temps réel devient la difficulté réseau rapportée sur eCash

Les chiffres de vérification de cet article ont été produits en évaluant la formule publiée sur les logs d’un nœud eCash en fonctionnement le 2 août 2026 et en comparant les résultats valeur par valeur.