Aller au contenu
Financial Context Wiki

Ajustement de la difficulté de Bitcoin : cibles, recalculs et limites

Bitcoin recalcule son seuil de preuve de travail tous les 2 016 blocs afin de ramener l'intervalle moyen de long terme vers dix minutes. Il faut distinguer cible, codage compact, fenêtre d'horodatage, bornes, règles de réseau et résultats probabilistes.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

L’ajustement de la difficulté de Bitcoin est une règle de consensus déterministe qui modifie périodiquement le plus grand hachage de preuve de travail acceptable, appelé target ou cible, afin de ramener l’intervalle moyen de long terme vers dix minutes lorsque le taux de hachage actif change. Sur le réseau principal, la cible reste normalement fixe pendant 2 016 blocs puis est recalculée pour la période suivante. Chaque nœud validateur déduit des en-têtes antérieurs la même cible obligatoire ; les mineurs ne votent pas et un explorateur ne la fixe pas.

La preuve de travail d’un en-tête n’est valide que si son hachage, interprété comme entier, est inférieur ou égal à la cible encodée dans le champ nBits de 32 bits. Une cible plus petite accepte moins de hachages et exige davantage d’essais en espérance. Par convention, la difficulté est une valeur relative inversement proportionnelle à la cible :

D = T₁ / T

Ici, T est la cible courante et T₁ la cible de référence pour une difficulté de 1. Cible et difficulté évoluent donc en sens opposé. Aucune ne mesure directement le nombre de machines, l’énergie, l’identité des mineurs ou le taux de hachage observé.

Dix minutes est une espérance, pas un horaire. Les essais de hachage et les arrivées de blocs sont aléatoires : deux blocs peuvent être séparés de quelques secondes ou aucun ne peut apparaître pendant une heure malgré une cible et un taux stables. Le recalcul est une rétroaction différée sur une période ; il réduit une dérive persistante de fréquence, mais ne supprime pas la variance à court terme et ne répond pas instantanément à un choc de puissance.

L’ajustement influe sur le rythme temporel des événements déclenchés par la hauteur, dont les réductions de subvention, mais ne définit ni les montants, ni l’intervalle de 210 000 blocs, ni l’offre finale. Il ne choisit pas non plus seul la chaîne canonique. Le choix de branche de Bitcoin compare le travail cumulé après validation des en-têtes et blocs ; la difficulté d’un bloc n’est pas un travail cumulé.

Comment analyser le recalcul

  1. Fixer le réseau et les règles. Réseau principal, ancien testnet, Testnet4, signet et regtest ne partagent pas toutes les exceptions. Notez la chaîne, les règles logicielles, la hauteur candidate et l’activation du recalcul ou des blocs spéciaux à difficulté minimale.
  2. Décoder la cible déclarée. Déployez le nBits compact de l’en-tête candidat en cible T. Rejetez toute cible négative, nulle, débordante ou supérieure à powLimit, puis exigez que le hachage respecte ≤ T.
  3. Repérer la frontière de période. Sur le réseau principal, une nouvelle cible est requise lorsque la hauteur candidate est divisible par 2 016. Aux autres hauteurs, le nBits du bloc précédent doit rester inchangé.
  4. Choisir la fenêtre d’horodatage. À une frontière du réseau principal, Bitcoin Core soustrait l’horodatage du premier bloc de la période précédente de 2 016 blocs à celui du dernier. Les extrémités contiennent 2 016 blocs, mais seulement 2 015 intervalles. La durée nominale demeure 2,016 × 600 = 1,209,600 secondes.
  5. Borner la durée écoulée. Posez t = clamp(t_actual, 302,400, 4,838,400) secondes, soit entre un quart et quatre fois les 14 jours nominaux. Les horodatages d’en-tête sont des champs de consensus fournis par les mineurs et soumis à d’autres contraintes, pas l’heure exacte de réception d’un nœud.
  6. Calculer et encoder la nouvelle cible. Avec les règles actuelles du réseau principal, calculez en entiers T_new = min(powLimit, T_old × t / 1,209,600), puis encodez le résultat de façon compacte dans nBits. Division entière et arrondi compact peuvent légèrement différer du ratio décimal idéal.
  7. Interpréter le résultat en probabilité. Approximativement, D_new / D_old = T_old / T_new. Comparez le recalcul à la distribution des temps de bloc et à un taux de hachage clairement qualifié d’estimation ; séparez-le des conclusions sur revenus, travail cumulé, concentration et risque de confirmation.

La formule du réseau principal prend la cible du dernier bloc comme T_old. Testnet4 diffère volontairement : BIP 94 autorise un bloc spécial de difficulté minimale après un horodatage suffisamment tardif, interdit l’exception au premier bloc d’une période et fonde le recalcul sur la difficulté réelle de ce premier bloc afin qu’une exception temporaire ne contamine pas la période suivante. Regtest désactive normalement le recalcul. Une règle sans réseau indiqué est incomplète.

Exemples détaillés

1. Une période nominale inchangée

Supposons T_old = 10 en unités de cible arbitraires et une durée mesurée exactement égale à 1,209,600 secondes. La borne ne change rien :

T_new = 10 × 1,209,600 / 1,209,600 = 10

Le ratio de difficulté vaut 10 / 10 = 1 : la difficulté idéalisée est inchangée. Cela ne signifie pas que chaque bloc a pris dix minutes ; les intervalles aléatoires rapides et lents peuvent se compenser.

2. Une période rapide de 12 jours

Supposons 12 jours entre les horodatages extrêmes. Cette durée étant dans les bornes, le ratio de cible est 12 / 14 = 6/7. La nouvelle cible vaut environ 85,7143 % de l’ancienne, tandis que :

D_new / D_old ≈ 14 / 12 = 1.166667

La difficulté idéalisée augmente donc d’environ 16,67 %, et non 14,29 %. La baisse en pourcentage de la cible et la hausse de difficulté diffèrent car ces grandeurs sont réciproques.

3. La borne d’un facteur quatre

Si les extrémités ne sont séparées que de 1,75 jour, le calcul emploie le minimum de 3,5 jours. La cible peut tomber à environ un quart de sa valeur et la difficulté être multipliée par environ quatre en un recalcul du réseau principal.

Si les horodatages couvrent 70 jours, le maximum de 56 jours est utilisé. La cible peut au plus quadrupler et la difficulté tomber à environ un quart, sauf si powLimit borne la cible plus tôt. « Facteur quatre » doit préciser s’il concerne cible ou difficulté et dans quel sens.

4. Un choc de taux de hachage à mi-période

Prenons une espérance simplifiée : les 1 008 premiers blocs sont minés au rythme correspondant à dix minutes et prennent environ sept jours. Puis 30 % du taux disparaît alors que la cible reste fixe. Les 70 % restants donnent un intervalle attendu de 10 / 0.70 ≈ 14.286 minutes ; les 1 008 derniers blocs prennent environ dix jours et la période entière environ 17.

En ignorant extrémités, hasard et arrondi compact, le multiplicateur de cible est 17/14 ≈ 1.214286 et celui de difficulté 14/17 ≈ 0.823529, soit une baisse d’environ 17,65 %. La baisse n’atteint pas 30 % car le choc n’affecte que la moitié de la période. Si le taux reste à 70 %, les blocs demeurent attendus plus lents que dix minutes après cet ajustement partiel et la période suivante poursuit la rétroaction.

Risques et échecs de revue

Erreurs de règles et de calcul

  • Appeler difficulté le seuil lui-même sans distinguer la cible de sa mesure relative inverse.
  • Inverser la formule de sorte qu’une période rapide relève la cible ou qu’une période lente relève la difficulté.
  • Traiter 2 016 blocs comme 2 016 intervalles horodatés mesurés ; le calcul actuel du réseau principal en couvre 2 015.
  • Oublier les bornes de 3,5 et 56 jours, powLimit, la division entière ou l’arrondi du nBits compact.
  • Appliquer une affirmation du réseau principal à Testnet4, l’ancien testnet, signet, regtest ou une autre chaîne de preuve de travail.
  • Prendre la prévision d’un explorateur pour une entrée de consensus plutôt qu’une estimation avant le bloc frontière.
  • Utiliser les heures locales de réception plutôt que les horodatages d’en-tête consommés par le calcul.
  • Confondre difficulté courante, travail par bloc, travail cumulé et résultat du choix de branche.

Mesure et inférence

  • Prendre le taux estimé pour un inventaire direct des machines actives plutôt qu’une inférence du travail et des arrivées aléatoires.
  • Extrapoler un recalcul depuis une petite part de la période où la variance ordinaire peut dominer.
  • Lire une hausse de difficulté comme preuve de hausse du prix, des revenus miniers, de l’énergie ou de la décentralisation.
  • Lire une baisse comme preuve d’échec du réseau sans examiner travail absolu, concentration et durée.
  • Comparer les difficultés de chaînes sans normaliser fonction de hachage, cible de référence et règles d’ajustement.
  • Décrire dix minutes comme délai, garantie de service ou temps de confirmation fixe.
  • Inférer la rentabilité sans récompenses, frais, disponibilité, conditions du pool, couvertures, électricité, financement et efficacité.

Sécurité et exploitation

  • Traiter le recalcul comme une protection immédiate contre une arrivée ou un départ brutal de puissance pendant la période.
  • Supposer qu’une difficulté moindre augmente la capacité des blocs ou résorbe instantanément une file de transactions.
  • Choisir une politique de confirmation sur la seule difficulté en ignorant travail cumulé, capacité de réorganisation et valeur.
  • Ignorer les incitations à manipuler l’horodatage et les mesures propres au protocole lors de l’évaluation d’un mécanisme.
  • Modifier calcul de consensus, indexation des frontières ou codage compact sans vecteurs inter-implémentations et plan d’activation.

Idées reçues

  • Chaque bloc Bitcoin prend dix minutes. Dix minutes est la moyenne cible avec un taux adapté ; chaque arrivée reste aléatoire.
  • Les mineurs votent la prochaine difficulté. Les nœuds validateurs calculent indépendamment le nBits permis ; un bloc déclarant une autre valeur est invalide.
  • Une cible 20 % plus petite donne une difficulté 20 % plus élevée. La relation est inverse : un multiplicateur de cible de 0,8 donne 1/0.8 = 1.25 pour la difficulté, soit 25 % de plus.
  • Le recalcul mesure directement le taux de hachage. Il répond à une production de blocs horodatée ; tout taux est une estimation avec des hypothèses d’échantillonnage et de temps.
  • La difficulté est la politique monétaire de Bitcoin. Le recalcul stabilise le rythme temporel de l’émission liée à la hauteur ; d’autres règles définissent subventions et réductions.

Sujets associés

Sources

Navigation

Rechercher dans le wiki...