Aller au contenu
Financial Context Wiki

Taux de hachage de Bitcoin : estimation, difficulté, part du mineur et sécurité

Le taux de hachage de Bitcoin estime les essais SHA-256 de preuve de travail par seconde ; ce n'est pas une mesure déclarée directement. Analysez séparément chaîne, travail cumulé, fenêtre, incertitude, retard de difficulté, part du mineur, mobilité du matériel, énergie et affirmations de sécurité.

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

Le taux de hachage de Bitcoin estime le nombre d’essais d’en-tête SHA-256 effectués par les mineurs chaque seconde sur un réseau de preuve de travail précis. Les unités progressent par 1 000 : H/s, kH/s, MH/s, GH/s, TH/s, PH/s et EH/s. Il faut préciser l’algorithme et le réseau : le débit SHA-256 d’un ASIC n’est pas comparable à celui d’un autre algorithme comme si les essais étaient interchangeables.

Le réseau n’impose pas aux mineurs de déclarer machines, sites ou débit instantané. Les observateurs déduisent une moyenne du travail accumulé par la chaîne canonique pendant une fenêtre. getnetworkhashps de Bitcoin Core divise la différence de chainwork par une différence de temps ; la fenêtre par défaut est nblocks = 120, tandis que moins un utilise les blocs depuis le dernier changement de difficulté. Des pointes, horodatages, fenêtres et réorganisations différents donnent des estimations différentes.

Le taux de hachage n’est pas la difficulté. La cible encodée dans nBits fixe la difficulté de trouver un en-tête ; le taux est le rythme d’essais estimé statistiquement. Si le taux varie pendant que la cible reste fixe, l’intervalle moyen varie jusqu’au prochain ajustement. Le hasard des arrivées peut aussi simuler une variation alors que le matériel est inchangé.

Il ne correspond pas non plus au travail de chaîne, à l’énergie, aux revenus, au coût d’attaque, à la décentralisation ou au prix. Plus de travail honnête par unité de temps augmente généralement les ressources nécessaires pour le dépasser avec le même algorithme, mais l’accès au matériel, les coûts, la coordination des pools, la concentration, la réaction et la durée comptent aussi. Un graphique ne prouve ni prévision de prix ni budget de sécurité exact.

Comment analyser le taux de hachage

  1. Fixez identité et unité. Notez chain, network, algorithm, client version, pointe canonique, préfixe et heure. Mainnet, testnet et une autre chaîne SHA-256 sont des populations distinctes même si le matériel peut migrer.
  2. Vérifiez la chaîne observée. Notez bestblockhash, hachages initial et final, hauteurs et ascendance. Décodez chaque cible depuis nBits, reproduisez le travail par bloc et rapprochez le chainwork cumulé ; ni nombre ni hauteur ne remplacent le travail.
  3. Reproduisez l’estimateur. Indiquez fenêtre, traitement des horodatages et limite de réorganisation. Pour Bitcoin Core, calculez estimated_hash_rate = work_diff / time_diff avec la fenêtre de l’implémentation et l’étendue entre temps minimal et maximal.
  4. Quantifiez le bruit d’échantillonnage. Comparez plusieurs fenêtres et montrez blocs, durée et confiance ou dispersion. Les fenêtres courtes réagissent vite mais subissent la chance de type Poisson ; les longues la lissent et détectent tard un arrêt réel.
  5. Séparez la rétroaction de difficulté. Identifiez cible active, frontière d’ajustement et règles du réseau. Modélisez d’abord l’intervalle avant ajustement, puis la réponse de la cible ; la difficulté n’est pas un capteur en temps réel.
  6. Modélisez part et économie du mineur. Divisez son taux effectif compatible par celui du réseau et indiquez disponibilité, méthode du pool, shares périmés, frais, subvention, prix, électricité, refroidissement, amortissement, financement et bridage. La part attendue ne garantit ni blocs quotidiens ni bénéfice.
  7. Testez sécurité et concentration. Examinez offre de matériel, taux louable ou transférable, contrôle des modèles, mobilité, géographie, énergie, durée d’attaque, profondeur et réponse défensive. Distinguez réorganisation et censure du vol de clés ou des changements arbitraires de règles.

Bitcoin Core calcule le travail d’un bloc à partir de sa cible compacte et l’accumule dans le travail de chaîne. L’estimateur divise la différence de travail entre la pointe et un bloc antérieur par le temps écoulé. C’est une estimation historique reproductible de la chaîne active du nœud, pas la télémétrie de tous les appareils.

Exemples calculés

1. Conversion des unités

Chaque préfixe multiplie par 1 000 : 1 EH/s = 1,000 PH/s = 1,000,000 TH/s = 10^18 H/s. Ainsi, 650 EH/s valent 650,000,000 TH/s, et non 650 millions de hachages par seconde. Conservez algorithme et unité : les mêmes valeurs pour deux fonctions ne signifient pas même matériel, coût ou sécurité.

2. Estimation par fenêtre

Supposons qu’une fenêtre de 120 blocs ajoute 4.32 * 10^22 hashes de travail représenté pendant une étendue minimale-maximale de 72,000 seconds. L’estimation illustrative est :

4.32 * 10^22 / 72,000 = 6.00 * 10^17 H/s = 600 EH/s

Cela ne signifie pas que les appareils ont déclaré exactement ce taux ni que chaque seconde était uniforme. Une courte fenêtre chanceuse estime davantage et une malchanceuse moins. Changer la pointe, la fenêtre ou la chaîne après réorganisation change l’échantillon.

3. Part du mineur et variance

Avec un réseau à 600 EH/s et un mineur compatible à 6 EH/s, la part simplifiée est 6 / 600 = 1%. Pour 144 blocs quotidiens, l’espérance est lambda = 144 * 1% = 1.44. Sous approximation de Poisson, la probabilité de zéro bloc ce jour-là est P(0) = exp(-1.44) = 23.69%.

Si le réseau monte à 750 EH/s et le mineur reste à 6 EH/s, sa part devient 6 / 750 = 0.8% et l’espérance 1.152. La part brute attendue en BTC baisse de 20% si le reste est constant, mais le résultat journalier demeure aléatoire et chaque pool applique ses règles de paiement.

4. Baisse avant le réajustement

Supposons une baisse de 600 EH/s à 420 EH/s, soit 30%, juste après un ajustement mainnet tandis que la cible reste fixe. L’intervalle attendu simplifié devient 10 / 0.70 = 14.29 minutes ; 2 016 blocs prendraient environ 20 days au lieu de 14.

Si le taux bas persiste et que l’on ignore les détails d’implémentation, la difficulté baisserait d’environ 30% au prochain ajustement et l’intervalle reviendrait près de dix minutes. Les arrivées sont aléatoires ; la fenêtre temporelle et l’arithmétique entière de cible de Bitcoin doivent être reproduites exactement. Une journée ne prouve pas un arrêt permanent.

Risques et erreurs de contrôle

Erreurs de mesure et de protocole

  • Présenter un taux déduit comme une somme exacte en temps réel déclarée par tous les mineurs.
  • Omettre chaîne, réseau, algorithme, unité, hachage de pointe, heure ou version de l’estimateur.
  • Confondre EH/s, PH/s et TH/s, ou comparer les taux bruts d’algorithmes incompatibles.
  • Employer nombre, hauteur ou dix minutes nominales au lieu du travail cumulé et du temps observé.
  • Mélanger des pointes concurrentes ou ne pas recalculer l’échantillon après une réorganisation.
  • Traiter les horodatages des mineurs comme des horloges parfaites ou changer silencieusement les règles d’extrémité, minimum, maximum ou médiane.
  • Choisir une courte fenêtre favorable sans montrer variance des arrivées ni comparaison longue.

Erreurs de minage et d’économie

  • Traiter la difficulté comme un taux mesuré ou supposer qu’elle change aussitôt que des machines arrivent ou partent.
  • Transformer la part attendue en blocs quotidiens garantis en ignorant variance et paiements du pool.
  • Assimiler la part de blocs d’un pool à la propriété du matériel malgré le taux délégué et mobile.
  • Convertir taux nominal en shares acceptés sans disponibilité, micrologiciel, température, travail périmé et bridage.
  • Déduire l’énergie directement du taux sans efficacité, utilisation, refroidissement et mix énergétique.
  • Appeler bénéfice en monnaie légale les récompenses brutes en BTC sans prix, frais, électricité, travail, amortissement, financement et couverture.
  • Affirmer que le taux cause le prix sans modèle de demande, liquidité et contrefactuel.

Erreurs de sécurité et d’interprétation

  • Utiliser un taux total élevé comme preuve de décentralisation sans concentration des pools, fabricants, zones et énergies.
  • Appeler le taux coût d’attaque exact sans accès au matériel, profondeur locative, transfert, durée et coût d’exploitation.
  • Prétendre qu’une majorité de hachage peut falsifier des signatures, voler tout portefeuille ou imposer une inflation invalide aux nœuds complets.
  • Traiter une brève majorité de pool comme propriété permanente de tout le matériel, ou nier tout risque de coordination.
  • Déduire une perte permanente de sécurité d’une journée bruitée sans contexte de difficulté, fenêtre et blocs.
  • Supposer que le taux élimine bogues, attaques eclipse, défaillances de garde, politiques de règlement ou risques de réponse sociale.

Idées reçues

  • Le taux du réseau est mesuré exactement en temps réel. Il est déduit du travail et du temps observés, donc dépend de la pointe, de l’estimateur et de la fenêtre.
  • Un taux supérieur garantit un prix de Bitcoin supérieur. Économie du minage et demande peuvent interagir, mais le protocole ne contient aucune fonction de prix.
  • Un attaquant à 51 % peut dépenser les pièces de chacun. La puissance de hachage ne crée pas de signatures privées et ne fait pas accepter d’inflation invalide aux nœuds.
  • La part du pool est le matériel de l’opérateur. Les pools coordonnent souvent des mineurs indépendants qui peuvent migrer, même si la concentration des modèles importe.
  • Une baisse journalière prouve un arrêt permanent. Les estimations courtes fluctuent avec les arrivées aléatoires ; comparez fenêtres et périodes de difficulté.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...