nBits et cible : comprendre l'encodage de la difficulté

Un bloc est accepté si le double SHA-256 de son en-tête est strictement inférieur à une cible. Cette cible est un grand entier qui ne voyage pas en forme longue dans l'en-tête : elle y est compactée dans le champ nBits. La difficulté affichée par un explorateur est encore une autre façon de désigner le même seuil.

La cible

Imaginez l'espace de tous les hashes possibles, soit 256 bits. La cible est un seuil dans cet espace, et un hash qui passe est un nombre inférieur à ce seuil. Plus la cible est petite, plus les hashes valides sont rares. Le protocole maintient un rythme de blocs proche de dix minutes en déplaçant ce seuil quand le travail collectif accélère ou ralentit.

Vous ne choisissez pas la cible réseau : les nœuds la dérivent de la chaîne. Le pool vous en donne une seconde, la cible de share, volontairement plus large, qui lui sert à compter votre travail entre deux blocs.

nBits, la même cible en compact

nBits est un encodage compact de la cible, sur quatre octets dans l'en-tête. Le protocole le décrit comme un exposant et une mantisse, à partir desquels on reconstitue le grand entier que l'on compare au hash.

Ce format compact existe parce que l'en-tête doit rester petit et de taille fixe. Recopier une cible de 32 octets dans chaque bloc n'apporterait rien que les nœuds ne sachent reconstruire. nBits est donc le contrat transporté, la cible étendue est ce que le vérificateur compare.

Deux points comptent en pratique :

• Tous les motifs de quatre octets ne forment pas une cible valide. Les nœuds appliquent des règles de bornes et de format, et un nBits fabriqué ne produit pas un bloc acceptable.
• nBits est identique pour tout le monde pendant une période de difficulté. Le firmware ne le règle pas, il le copie depuis le job reçu.

Le détail bit à bit de l'encodage figure dans le protocole et dans le code des nœuds. Si vous écrivez un parseur, partez de ces sources plutôt que d'un article.

Difficulté, la cible à l'envers

La difficulté est un ratio entre la cible actuelle et une cible de référence historique, le maximum prévu par le protocole, associé à la difficulté 1. Plus le ratio est élevé, plus la cible actuelle est petite. Difficulté et cible disent donc la même chose en sens inverse.

Les interfaces mélangent volontiers ces mots. Pour un opérateur, il faut distinguer trois objets :

• la cible réseau, ou nBits : le puzzle du prochain bloc ;
• la difficulté réseau : ce même puzzle dans une unité plus lisible ;
• la difficulté de share : le compteur du pool, délibérément plus bas.

Les confondre produit de mauvais diagnostics. Un exemple courant : croire qu'un retarget du réseau doit modifier votre débit de shares à difficulté de pool constante. Votre machine hashe exactement autant ; ce qui bouge, c'est la valeur de ce travail face au puzzle global.

Le recalcul se fait tout seul

Tous les 2016 blocs, le réseau compare le temps écoulé au temps visé, soit 2016 fois dix minutes, et déplace la cible, donc nBits, donc la difficulté. L'ajustement est borné d'un retarget à l'autre, et entre deux, nBits reste constant.

Vous n'avez jamais à recalculer nBits pour miner. En revanche, si un job affiche un nBits qui ne correspond pas à la pointe de chaîne que voit votre nœud, le problème vient du template, pas de votre nonce.

Trois réflexes utiles

• Lisez nBits comme l'identité de la période de difficulté en cours, ce qui permet de dater un job d'un coup d'œil.
• Quand un explorateur, un pool et un firmware affichent trois difficultés différentes, vérifiez d'abord de quel objet chacun parle. La comparaison n'a de sens qu'à unité identique.
• N'utilisez jamais une cible d'archive dans un tableur de prévision : elle appartient à une période de difficulté révolue, et toute projection bâtie dessus sous-estime la difficulté réelle.