Aller au contenu
Financial Context Wiki

Consensus de Nakamoto : validité, travail cumulé, confirmations et réorganisations

Le consensus de Nakamoto combine règles de validité appliquées indépendamment, production sans permission de blocs par preuve de travail, propagation et sélection de la chaîne valide au travail cumulé maximal. Il faut analyser séparément vues locales, chainwork, confirmations, réorganisations, hypothèses de préfixe commun, incitations et attaques réseau.

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 consensus de Nakamoto est le processus de type Bitcoin dans lequel les nœuds appliquent indépendamment les règles de validité, les producteurs de preuve de travail prolongent les blocs sans liste permissionnée de membres, les blocs se propagent sur un réseau pair à pair et chaque nœud choisit la branche valide qui représente le plus de travail cumulé. Il ordonne les transactions valides selon la vue observée par le nœud ; il ne rend pas valide une transaction invalide, n’établit pas les faits extérieurs au registre et ne crée pas de finalité déterministe immédiate.

La validité précède le choix de chaîne. Une branche comportant un en-tête, une preuve de travail, une transaction, un script, une sortie déjà dépensée, un montant coinbase ou une limite de bloc invalide est rejetée, quels que soient la hauteur ou le travail revendiqués. Parmi les branches conformes aux règles du nœud et dont les données sont disponibles, le chainwork cumulé, non le seul nombre de blocs, détermine la chaîne active. « Chaîne la plus longue » est donc l’abréviation informelle de la chaîne valide représentant le plus d’effort de preuve de travail.

La pointe active est provisoire. Des blocs valides concurrents peuvent temporairement donner des vues locales différentes à des nœuds honnêtes bien connectés ; du travail supplémentaire résout généralement le fork, et un nœud peut déconnecter une branche puis en connecter une autre lors d’une réorganisation. Le nombre de confirmations mesure la profondeur d’une transaction dans la chaîne active actuelle de l’observateur. Une profondeur accrue peut réduire la probabilité de rattrapage dans un modèle de hashrate et de réseau précisé, mais aucun nombre n’est universellement final.

Le terme recouvre plus que le hachage. Son argument de sécurité dépend aussi de la validité des blocs et transactions, de la propagation pair à pair, de l’adoption honnête de la chaîne valide au travail maximal, d’une puissance minière effective honnête suffisante, du comportement économique et de l’observation indépendante du réseau et du logiciel voulus. Préfixe commun, croissance de chaîne et qualité de chaîne sont des propriétés formelles démontrées uniquement dans des modèles déclarés, pas des faits inconditionnels de toute chaîne de preuve de travail déployée.

Comment analyser le consensus de Nakamoto

  1. Fixer l’identité et le périmètre d’observation. Consignez chain, network, genesis hash, client version, règles de consensus, checkpoints ou paramètres assume-valid, observateur, pairs et heure. Capturez bestblockhash, height et chainwork ; deux nœuds peuvent honnêtement signaler des pointes différentes pendant la propagation.
  2. Valider avant de comparer le travail. Vérifiez chaînage des en-têtes, contraintes temporelles, cible décodée, preuve de travail, engagements Merkle et witness, transactions, scripts, dépenses UTXO, coinbase et limites de ressources. Une branche invalid ne devient pas admissible en revendiquant davantage de hauteur ou de travail.
  3. Reconstruire l’arbre observé. Reliez chaque candidat à un ancêtre connu par le hash du bloc précédent et distinguez blocs complets et seuls en-têtes. Rapprochez les états active, valid-fork, valid-headers, headers-only et invalid via des interfaces comme getchaintips ; toute pointe visible n’est pas une chaîne concurrente valide.
  4. Recalculer le travail cumulé. Décodez la cible nBits de chaque en-tête et calculez le travail représenté selon les règles entières de l’implémentation, conceptuellement work = floor(2^256 / (target + 1)). Additionnez le long de l’ascendance et comparez les branches valides depuis l’ancêtre commun ; hauteur, hashrate estimé et étiquettes de pools ne remplacent pas chainwork.
  5. Tracer sélection et réorganisation. Reproduisez le choix du candidat au travail maximal, l’ordre local à travail égal et l’état d’arrivée. Si une meilleure branche valide apparaît, identifiez le fork, déconnectez l’ancien suffixe, connectez le nouveau, mettez à jour l’UTXO set et rapprochez les transactions du mempool et des enregistrements applicatifs.
  6. Définir une politique de confirmation fondée sur le risque. Calculez confirmations = tip_height - block_height + 1 uniquement pour un bloc de la chaîne active actuelle. Déclarez valeur exposée, réversibilité, part adverse, propagation, exposition eclipse, taux stale observé, profondeur et plan de réponse ; six est une convention, pas un seuil de finalité du protocole.
  7. Tester tout l’argument sous contrainte. Testez partitions, latence, rétention de blocs, selfish mining, attaques eclipse, concentration des pools et du matériel, changements brusques de hashrate, incitations des frais et subventions, divergence des clients, réorganisations profondes et reprise. Ne reliez les conclusions au préfixe commun, à la croissance, à la qualité, à la persistance et à la vivacité que sous les hypothèses du modèle cité.

Le résultat est une explication reproductible et propre à l’observateur de l’historique valide qu’un nœud choisit actuellement et de sa raison. Les règles définissent l’admissibilité ; la preuve de travail renchérit les historiques alternatifs ; la propagation expose le travail ; le fork choice choisit l’historique courant ; et la politique de confirmation décide quand l’application agit. Réduire ces couches à une « approbation du réseau » masque les conditions susceptibles d’échouer.

Exemples détaillés

1. Le travail invalide ne gagne pas

Supposons que la branche A indique valid_A = false et chainwork_A = 1,200 units, tandis que B possède valid_B = true et chainwork_B = 1,000 units. Le nœud rejette A et choisit B. Le travail n’est comparé qu’entre candidats admissibles ; la preuve de travail n’autorise ni coinbase excessive, ni signature invalide, ni double dépense.

Si un observateur ne possède que les en-têtes de A et un autre ses blocs complets, leurs états peuvent différer jusqu’à la fin du téléchargement et de la validation. Des en-têtes valides ne prouvent pas que toutes les transactions et transitions ont été entièrement validées.

2. La hauteur n’est pas le travail cumulé

Dans un exemple simplifié à cible variable, C ajoute six blocs représentant chacun 100 unités, soit 6 * 100 = 600 units. D en ajoute cinq de 130 unités, soit 5 * 130 = 650 units. Si les deux sont valides et partent du même travail, D est la branche au travail maximal malgré un bloc de moins.

Si deux pointes valides ont exactement 650 units, l’égalité n’oblige pas tous les nœuds à voir immédiatement la même pointe. Ordre d’arrivée et état local peuvent différer jusqu’à ce qu’un autre bloc valide alourdisse une branche. Une vue transitoire à égalité n’est pas une finalité mondiale déterministe.

3. Des confirmations peuvent être retirées

Une transaction incluse à la hauteur 100 alors que la pointe active est 105 a tip_height - block_height + 1 = 105 - 100 + 1 = 6 confirmations. Supposons qu’une branche valide alternative bifurque après 99 et devienne celle au travail maximal à la hauteur 106 sans cette transaction. La réorganisation déconnecte les anciens blocs 100 through 105 ; la transaction perd ses six confirmations actives et peut retourner au mempool, entrer en conflit ou rester absente.

Les applications doivent rapprocher hash et ascendance, pas seulement stocker le nombre six. Crédit d’exchange, biens livrés, messages de bridge et règlement de dérivés peuvent être économiquement irréversibles alors que l’historique source ne l’est pas.

4. La probabilité de rattrapage dépend du modèle

Dans le modèle illustratif du livre blanc Bitcoin, soit la part adverse q = 0.10, la part honnête p = 0.90 et l’avance honnête z = 6. L’approximation de Poisson donne lambda = z * (q / p) = 0.6666667 et P(catch up) = 0.0002428027 = 0.02428027%. Avec q = 0.30 à profondeur égale, elle atteint P(catch up) = 0.1321111687 = 13.21111687%.

Ces chiffres ne sont pas des garanties actuelles de Bitcoin. Le calcul suppose des essais de hachage indépendants et stables et les conditions de course du modèle ; il omet isolement eclipse, avantage de propagation, stratégies selfish, réactions de prix et location, bogues et réponse applicative. Une politique doit déclarer son modèle et tester de pires conditions, pas seulement citer six confirmations.

Risques et erreurs de contrôle

Erreurs de protocole et de mesure

  • Comparer le travail avant validation indépendante de l’en-tête, du corps et de l’ascendance.
  • Déclarer gagnante la branche la plus haute ou vue en premier sans calculer le chainwork cumulé.
  • Utiliser nombre de blocs, hashrate nominal, part de pool ou étiquette d’explorateur comme proxy de chainwork.
  • Mélanger mainnet, testnet, signet, forks, versions client, checkpoints ou identités genesis.
  • Traiter données d’en-têtes seuls, indisponibles ou optimistes comme historique pleinement validé.
  • Omettre décodage de cible, arithmétique entière, lien du hash précédent ou ancêtre commun.
  • Lire un RPC ou explorateur comme vue globale sans contexte de hash, hauteur, heure et pairs.

Erreurs de réseau, d’incitation et de contrôle

  • Supposer une propagation instantanée ou le même ordre d’arrivée à tous les nœuds.
  • Traiter une égalité de travail comme état mondial unique, non comme vues locales temporaires.
  • Ignorer blocs stale, latence, rétention, selfish mining et avantage de propagation.
  • Déduire des mineurs indépendants des noms de pools ou la propriété matérielle de leurs parts.
  • Omettre concentration des pools, firmwares, fabricants, hébergeurs, énergie, géographie et réseau.
  • Considérer les récompenses comme preuve que l’extension honnête est toujours optimale pour tous.
  • Omettre exposition aux attaques eclipse, partitions, Sybil, empoisonnement des pairs, DoS et manipulation temporelle.

Erreurs de règlement et de sécurité

  • Appeler une confirmation finalité du protocole ou promettre que six ne peuvent être retirées.
  • Appliquer un même nombre à toute valeur, contrepartie, réversibilité et menace.
  • Transformer l’exemple probabiliste du livre blanc en probabilité d’attaque mesurée aujourd’hui.
  • Affirmer qu’une majorité de hash peut falsifier des signatures, prendre des coins arbitraires ou valider l’inflation.
  • Affirmer qu’une minorité ne peut dévier avec profit ni causer réorganisation ou censure.
  • Assimiler la pointe au travail maximal aux faits externes, à la propriété juridique ou au règlement applicatif.

Idées reçues

  • La chaîne la plus longue a toujours le plus de blocs. Les nœuds Bitcoin choisissent la chaîne valide au travail cumulé maximal ; la hauteur peut être un mauvais proxy si les cibles diffèrent.
  • Les mineurs décident quelles règles sont valides. Ils proposent des blocs ; chaque nœud complet applique indépendamment ses règles configurées.
  • Six confirmations créent une finalité absolue. Six est une convention ; le risque dépend du modèle, de la profondeur, de l’adversaire, de la propagation et de l’intégrité d’observation.
  • Un attaquant à 51 % peut dépenser les coins d’autrui. Le hash peut soutenir réorganisation, double dépense et censure, mais ne fournit pas la signature privée d’autrui et ne fait pas accepter une inflation invalide aux nœuds inchangés.
  • Un hashrate total élevé prouve décentralisation et sécurité. Contrôle effectif, visibilité, matériel, coordination des pools, diversité des clients, incitations et durée comptent aussi.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...