Aller au contenu

Preuve de travail

La preuve de travail rend la recherche d’un bloc coûteuse et sa vérification peu coûteuse en exigeant une preuve computationnelle définie par le protocole. Analysez séparément la validité, la probabilité de la cible, le travail cumulé, la difficulté, les confirmations, l’économie du minage, la concentration et les hypothèses énergétiques.

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

La preuve de travail (PoW) est une famille de mécanismes dans laquelle un participant doit produire une preuve computationnelle définie par le protocole, coûteuse à rechercher mais peu coûteuse à vérifier. Dans une blockchain typique fondée sur le hachage, le producteur modifie les données candidates jusqu’à ce que le hachage obtenu soit numériquement inférieur ou égal à la cible. La preuve acceptée montre qu’un résultat admissible a été trouvé pour cette entrée exacte et ces règles ; elle ne montre ni le nombre de machines utilisées, ni leurs sources d’énergie, ni le calcul effectif de chaque hachage intermédiaire revendiqué.

PoW fournit une résistance Sybil en pondérant les opportunités de production de blocs avec une computation rare plutôt qu’avec des identités, des comptes ou des soldes de jetons. Ce n’est qu’un seul composant d’un système de consensus déployé. Les nœuds doivent valider indépendamment l’en-tête, les transactions, les signatures, les règles de sortie dépensée, l’émission, les limites et d’autres règles de transition d’état. Un bloc avec un travail revendiqué énorme reste invalide si ses transactions ou sa récompense violent le consensus.

Bitcoin combine le travail d’en-tête SHA-256d avec des règles spécifiques au réseau pour les cibles et les recibles, la propagation pair-à-pair, la validation indépendante des blocs et la sélection de la branche valide ayant le plus grand cumul de travail de chaîne. « Chaîne la plus longue » est un raccourci informel pour désigner le travail valide le plus accumulé, et pas nécessairement la branche ayant le plus grand nombre de blocs. D’autres systèmes PoW peuvent utiliser différents puzzles, entrées, règles d’ajustement, formules de travail, intervalles de blocs, calendriers de récompense et règles de choix de fourche.

PoW rend la réécriture de l’histoire acceptée nécessitant un travail concurrent sous des hypothèses de réseau et d’adversaire énoncées, mais il ne crée pas de finalité déterministe. Les blocs concurrents, la propagation retardée, les partitions, le minage égoïste, la puissance de hachage louée ou redirigée, les défauts logiciels et les incitations économiques affectent la sécurité. La profondeur de confirmation réduit certains risques de réorganisation uniquement dans un modèle spécifié ; elle ne peut pas prouver la vérité hors chaîne, des contreparties correctes, la propriété légale, la valeur future d’un actif ou l’irréversibilité permanente.

Comment analyser Preuve de travail

  1. Délimitez le système et les règles. Consignez le réseau, la genèse, la version du client, l’état d’activation, l’algorithme de travail, l’entrée candidate, le codage et le maximum de la cible, la règle d’ajustement, la règle de choix de fork, l’observateur, les pairs et l’horodatage. N’appliquez pas les paramètres du mainnet Bitcoin à une autre chaîne ou à un réseau de test.
  2. Validez indépendamment le bloc candidat. Reconstruisez l’en-tête et les données engagées par le bloc ; vérifiez ensuite transactions, signatures, scripts ou exécution, règles sur les états dépensés, émission, engagements, limites de taille ou de poids et ascendance. PoW se vérifie en plus de la validité, pas à sa place.
  3. Reproduire le test de travail. Appliquez exactement l’algorithme de hachage ou de puzzle et la sérialisation, décodez la cible, rejetez les plages ou encodages invalides, et testez l’inégalité du protocole telle que work_hash <= target. Séparez l’ordre des octets affiché de la comparaison des entiers utilisée par le consensus.
  4. Quantifier la probabilité de recherche. Pour un hachage uniforme de n bits et une cible inclusive T, un essai réussit avec p = (T + 1) / 2^n, et les essais attendus sont 1 / p. Indiquez le taux de hachage compatible effectif et le temps de disponibilité ; le temps attendu n’est pas une échéance et les échecs passés n’augmentent pas la probabilité que le prochain essai indépendant réussisse.
  5. Reconstruire le travail cumulatif et le choix de branche. Pour chaque branche valide, dérivez le travail de chaque bloc à partir de sa cible en utilisant la règle entière du réseau, faites-en la somme sur l’ascendance, et appliquez le comportement réel des liens et de la disponibilité. Comparez le travail cumulé, pas la hauteur, la difficulté affichée ou un seul en-tête isolément.
  6. Évaluez la confirmation et attaquez les hypothèses. Enregistrer la profondeur des transactions dans la chaîne active de l’observateur, la propagation, le taux de blocs obsolètes, les partitions, la diversité des pairs, la concentration des mineurs et des pools, les marchés alternatifs de hachage, la censure, la rétention et la capacité de réorganisation. Évitez de présenter une limite ou un nombre de confirmations universel « 51% ».
  7. Réconcilier l’économie et les externalités. Séparez les subventions, frais, conditions du pool, variance, prix, difficulté, efficacité, puissance, refroidissement, hébergement, temps d’arrêt, amortissement, financement et taxes. Estimez l’électricité uniquement à partir du taux de hachage avec une distribution d’efficacité du matériel datée et les frais généraux de l’installation ; estimez les émissions uniquement après avoir ajouté le lieu, le temps, le mix énergétique, la limitation et l’incertitude méthodologique.

Les preuves résultantes devraient maintenir cinq couches distinctes : un candidat valide, une preuve valide pour ce candidat, le travail cumulatif d’une branche, le choix actuel de la chaîne active du nœud, et la politique de règlement d’une application. Fusionner ces couches produit la plupart des erreurs d’interprétation PoW.

Exemples travaillés

1. Probabilité cible et asymétrie de vérification

Supposons qu’une règle de hachage uniforme pour jouet accepte une sortie dans 2^20. La probabilité de succès par essai indépendant est p = 1 / 1,048,576, donc le nombre attendu d’essais est 1,048,576. À 5,000,000 hashes/second, le temps de recherche attendu est :

1,048,576 / 5,000,000 = 0.2097152 seconds

La vérification nécessite un hachage et une comparaison de cible une fois que le candidat est fourni. Pourtant, le temps attendu n’est pas une garantie : après 1,000,000 essais, la probabilité de ne pas réussir est d’environ (1 - 1/1,048,576)^1,000,000 = 38.53%. Un essai échoué ne rend pas le prochain essai « dû ».

2. Validité avant le travail cumulatif

La branche A contient six blocs valides valant chacun 100 unités de travail, pour 600. La branche B contient cinq blocs valides valant chacun 130, pour 650. Selon la règle de travail le plus cumulatif, B l’emporte malgré le fait qu’elle ait moins de blocs.

Supposons maintenant que la branche C revendique 1,200 unités de travail mais crée une récompense invalide. Son travail est sans conséquence pour un nœud de validation honnête : C est rejetée avant la comparaison des branches. PoW limite qui peut étendre à moindre coût l’historique valide ; elle n’achète pas une exception aux règles de validité.

3. Partage de hachage et variance de bloc

Supposons un taux de réseau compatible illustratif de 500 EH/s et un taux de mineur de 2 PH/s. La part simplifiée du mineur est :

2 PH/s / 500 EH/s = 0.000004 = 0.0004%

À un rythme supposé de 144 blocs par jour, les blocs solo attendus sont 144 * 0.000004 = 0.000576 per day, ce qui implique une attente moyenne d’environ 1 / 0.000576 = 1,736.11 days. Une approximation de Poisson donne P(0) = exp(-0.000576) = 99.9424% pour aucun bloc ce jour-là. Cette estimation n’est ni une promesse de paiement ni une preuve qu’un pool doit une certaine somme au mineur.

4. Du taux de hachage à une estimation énergétique

Supposons qu’un analyste modélise 500 EH/s en utilisant une efficacité moyenne de flotte de 25 J/TH. Parce que 500 EH/s = 500,000,000 TH/s, la puissance de la machine modélisée est :

500,000,000 TH/s * 25 J/TH = 12.5 GW

Avec une efficacité d’utilisation de l’énergie de l’installation supposée de 1.10, la demande totale modélisée devient 12.5 * 1.10 = 13.75 GW, ou 13.75 * 8,760 = 120.45 TWh annualisée si les conditions restaient constantes. Il s’agit d’une estimation, pas d’une lecture de compteur. Modifier le mélange de matériel, le temps de fonctionnement, les frais généraux de l’installation ou la fenêtre de taux de hachage change le résultat ; les émissions nécessitent des hypothèses géographiques et de génération supplémentaires.

Risques et échecs de révision

Erreurs de protocole et de validité

  • En traitant PoW comme le protocole de consensus complet : Le puzzle ne définit pas la validité des transactions, la propagation, le choix de la branche, les récompenses ou le règlement des applications. Documentez toutes les règles environnantes.
  • Réseau ou algorithme incorrect : Une preuve valide sur une chaîne, un fork, un réseau de test ou une fonction de hachage peut n’avoir aucun sens ailleurs. Liez les éléments probants à la genèse et aux règles actives.
  • Entrée sérialisée incorrecte : Omettre un champ, un engagement, une règle d’ordre des octets ou une mutation permise peut tester un puzzle différent. Reconstruisez les octets candidats exacts.
  • Raisonnement travail-avant-validité : Un travail important ne peut pas légaliser des signatures invalides, des doubles dépenses, des émissions ou des transitions d’état. Validez le candidat complet avant de comparer les branches.
  • Inversion de cible et de difficulté : Une cible plus petite est plus difficile, tandis que la difficulté affichée est généralement une mesure relative inverse. Vérifiez les formules entières exactes du réseau.
  • Hauteur au lieu de travaux de chaîne : Plus de blocs ne signifie pas nécessairement plus de travail cumulatif lorsque les objectifs par bloc diffèrent. Additionnez le travail dérivé du protocole sur l’ascendance valide.
  • Hypothèses de reciblage entre réseaux : La cadence d’ajustement, les horodatages, les bornes, les règles d’urgence et les cibles maximales diffèrent. Ne décrivez jamais un design comme le comportement universel de PoW.

Erreurs de sécurité et de réseau

  • Revendication de finalité déterministe : Les chaînes PoW peuvent se réorganiser. Définissez la politique de confirmation à partir de la valeur, de la profondeur, du travail observé, de la liquidité, de la capacité de l’adversaire et de la réponse opérationnelle.
  • 51 % comme seuil universel : La rétention de blocs, les avantages de propagation, les attaques par éclipse, la corruption, le hachage loué et la politique de l’application peuvent compter au-dessous comme au-dessus de cette part nominale. Énoncez le modèle.
  • Réclamation de pouvoir invalide :La majorité de la puissance de hachage peut censurer ou réorganiser et peut surpasser l’historique valide, mais elle ne peut pas obliger les nœuds honnêtes à accepter des signatures falsifiées ou une inflation invalide.
  • Le taux de hachage équivaut à la décentralisation : Les modèles de blocs des pools, le contrôle effectif, le firmware, les fabricants, l’hébergement, la géographie, les fournisseurs d’énergie et les logiciels peuvent rester concentrés.
  • Taux de hachage estimé comme télémétrie : Le taux de hachage du réseau est déduit du travail et des arrivées aléatoires de blocs ; ce n’est pas un recensement direct des machines, des opérateurs ou de la capacité.
  • Ignorer les partitions et les attaques par éclipse : Un nœud avec une vue restreinte peut suivre un travail obsolète ou frauduleux malgré un taux de hachage global élevé. Examinez la diversité des pairs et du réseau.
  • Ignorer le contrôle du pool et du modèle : De nombreux mineurs nominaux peuvent suivre un modèle de bloc ou un opérateur de paiement. Séparez la propriété physique du hachage, l’autorité du modèle et la garde des récompenses.

Économie, énergie et externalités

  • Récompense attendue comme flux de trésorerie garanti : Les résultats de recherche sont aléatoires, tandis que les pools ajoutent des règles de parts, des réserves, des frais, une maturité, une garde et une exposition au défaut.
  • Production brute de jetons comme profit : Le prix, les frais, la difficulté, la disponibilité, la puissance, le refroidissement, la main-d’œuvre, l’hébergement, les réparations, la dépréciation, le financement, les couvertures et les impôts peuvent inverser le résultat.
  • Le taux de hachage équivaut directement à l’électricité : La conversion nécessite l’efficacité matérielle, l’utilisation, la composition de la flotte, le refroidissement et les frais généraux des installations au même moment d’observation.
  • L’électricité équivaut directement aux émissions : L’impact carbone du dépend de l’emplacement, de la production marginale et moyenne, du temps, des contrats, de la limitation de production, des déclarations de méthane et des limites comptables.
  • L’efficacité garantit une utilisation totale moindre :Un matériel plus efficace réduit l’énergie par hachage, mais la concurrence sur le réseau, le prix, les récompenses et le déploiement peuvent modifier le taux de hachage total et la demande.
  • Ignorer les externalités et contraintes locales : La congestion du réseau, le bruit, la chaleur, l’eau, le sol, le renouvellement des équipements, les déchets électroniques, les subventions et la réduction de charge peuvent affecter les communautés et les opérations.

Idées reçues

Preuve de travail rend chaque transaction dans un bloc miné valide

Non. Un en-tête qualifiant prouve seulement que son candidat a respecté la règle de travail. Les nœuds complets rejettent indépendamment les transactions, engagements, récompenses ou transitions d’état invalides, quelle que soit la dépense du mineur.

Le travail est de l’énergie stockée qui rend un bloc irréversible physiquement

Le bloc contient une preuve compacte et vérifiable, pas de l’électricité récupérable. Un travail valide concurrent peut réorganiser l’historique, et des défaillances sociales ou logicielles peuvent encore imposer des décisions de récupération. PoW augmente le coût de réécriture sous certaines hypothèses ; il ne crée pas de finalité physique ou déterministe.

La chaîne la plus longue signifie toujours la chaîne avec le plus de blocs

Pas nécessairement. Le noyau Bitcoin compare le travail cumulatif de la chaîne parmi les candidats valides. Une branche plus courte peut représenter plus de travail lorsque ses blocs ont été produits contre des cibles plus difficiles.

Un attaquant disposant de la majorité de la puissance de hachage peut voler n’importe quelle pièce ou modifier n’importe quelle règle

La puissance de calcul peut créer des risques de réorganisation, de censure, d’ordonnancement et de déni de service, mais les nœuds honnêtes font toujours respecter les signatures, l’émission et les règles de consensus. Modifier ces règles nécessite que les utilisateurs exécutent un logiciel compatible ; le travail seul ne forge pas l’autorisation.

Un graphique de taux de hachage révèle la consommation exacte d’électricité et les émissions

Ce n’est pas le cas. L’électricité est modélisée à partir d’hypothèses incertaines concernant les équipements et les installations, et les émissions ajoutent des hypothèses sur l’emplacement, la production, le calendrier et la comptabilité. Les estimations responsables divulguent des plages et la méthodologie plutôt que de présenter un chiffre exact unique.

Sujets liés

Sources

Navigation

Rechercher dans le wiki...