Nakamoto Consensus désigne la manière dont Bitcoin établit un historique valide et partagé sans arbitre central. Un Full Node, un ordinateur équipé d’un logiciel qui vérifie les règles, rejette d’abord les blocs invalides. Parmi les branches valides, il choisit ensuite celle qui cumule le plus de travail. Les confirmations renforcent la confiance dans un paiement sous certaines hypothèses de sécurité ; elles ne le rendent pas immédiatement irréversible.
Anna envoie un paiement à Pierre. Elle pourrait aussi signer une autre transaction dépensant les mêmes fonds au profit d’Eva. Signer signifie ici utiliser une clé privée, une valeur numérique secrète, pour créer une preuve vérifiable de l’autorisation du paiement. Les autres peuvent vérifier la signature sans connaître ce secret. Les deux signatures pourraient être authentiques, mais les deux paiements ne peuvent appartenir au même historique valide. Pierre et Eva pourraient même recevoir les messages dans un ordre différent. Bitcoin a donc besoin de plus qu’une vérification des signatures : il doit établir un ordre commun et empêcher la double dépense. Nakamoto Consensus associe règles, Proof of Work, choix de branche et rémunération des mineurs. Le livre blanc de Satoshi, le document technique présentant Bitcoin à l’origine, n’utilise pas cette appellation ultérieure. [1] [4]
Le Full Node de Pierre n’est pas un bulletin de vote. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Une sortie de transaction enregistre un montant et les conditions permettant de le dépenser ensuite. Le logiciel du Full Node contrôle lui-même les transactions et les blocs : les sorties que l’on veut dépenser sont-elles encore disponibles, leurs conditions de dépense sont-elles remplies, et la création de bitcoins respecte-t-elle le montant autorisé ? Un mineur peut proposer un bloc, mais pas contourner ces contrôles à sa guise. Un bloc invalide le reste même avec énormément de travail derrière lui. Seules les branches valides sont comparées ; partager un historique suppose des règles compatibles entre participants. [2] [3]
Si chaque ordinateur connecté disposait d’une voix, un attaquant pourrait créer de nombreux participants apparemment indépendants. C’est une Sybil Attack. Au lieu de compter les noms, Proof of Work lie le poids d’une branche à un travail de calcul vérifiable. Les mineurs calculent sans cesse des hashes, des empreintes numériques de données, en cherchant un résultat qui respecte une condition donnée. Les essais exigent énergie et matériel ; le résultat trouvé se vérifie facilement. Multiplier les identités réseau ne crée pas de travail supplémentaire. Ce n’est ni un contrôle d’identité ni un vote de tous les nœuds. [1] [4]
Un mineur assemble un bloc candidat et fait varier son en-tête, un résumé compact du bloc, jusqu’à obtenir un hash dont la valeur numérique est inférieure ou égale à la cible valide. Il ne résout pas une équation utile et ne casse pas un chiffrement : il cherche un résultat rare. Deux mineurs peuvent réussir presque simultanément. Une partie du réseau voit un bloc en premier, l’autre voit son concurrent ; deux branches valides coexistent brièvement. Ce n’est pas en soi une panne. Avec une propagation normale, le travail ultérieur permet de converger vers la branche la plus forte. [1] [8]
La force d’une branche se mesure par le chainwork, la somme du travail attribué aux blocs à partir de leur cible. Ce n’est ni un compteur électrique ni le relevé des essais réellement effectués. Un mineur peut avoir de la chance immédiatement, un autre attendre longtemps : à cible égale, leurs blocs valides ont le même poids. Un Full Node choisit la branche valide disponible dont la somme est la plus élevée. « La chaîne la plus longue » signifie donc le plus de travail, pas nécessairement le plus de blocs. Changer de branche est une réorganisation ; un paiement d’un bloc abandonné peut être inclus à nouveau s’il reste valide. [1] [2] [3] [7]
Dès que le paiement d’Anna entre dans un bloc accepté, il possède une confirmation. Chaque bloc suivant en ajoute une. Pour remplacer cet historique, une branche concurrente devrait rattraper son travail. Avec une majorité honnête de puissance de calcul et une propagation assez rapide, le risque de réécriture réussie diminue généralement avec la profondeur. C’est la finalité probabiliste : une confiance croissante, pas une impossibilité mathématique de changement. Le nombre de confirmations attendu par Pierre dépend aussi du montant et du risque. Aucun nombre universel ne garantit la sécurité en toute circonstance. [1] [4]
Si la condition restait inchangée à l’arrivée de machines plus rapides, les blocs arriveraient plus vite. Difficulty Adjustment recalcule donc la cible du réseau principal tous les 2016 blocs à partir des horodatages précédents. Il vise une moyenne de dix minutes par bloc, soit environ deux semaines pour cet intervalle. Un bloc particulier peut arriver bien plus tôt ou plus tard. Le déclencheur est un nombre de blocs, pas une date : si une grande partie de la puissance disparaît, le prochain ajustement peut être retardé. Ce n’est ni un régulateur instantané ni une horloge précise. [2] [8]
Les bitcoins nouvellement émis, la subvention de bloc, et les frais de transaction rémunèrent les mineurs pour les blocs qui restent dans l’historique accepté. Cela encourage à le prolonger, sans remplacer les hypothèses de sécurité. Une majorité de puissance peut réorganiser des branches valides, omettre des paiements et tenter d’annuler ses propres dépenses. Elle ne peut pas imposer à un Full Node une signature invalide, une émission excessive ou la dépense non autorisée des fonds d’autrui. Le seuil de 50% n’est pas non plus un interrupteur de sécurité : certains scénarios d’attaque restent possibles en dessous. La rémunération ne crée pas à elle seule l’honnêteté. [1] [2] [3]
Revenons à Pierre. Si un attaquant contrôle toutes les connexions de son nœud, il peut lui présenter une vision incomplète des événements. Une Eclipse Attack est précisément cet isolement réseau ; les confirmations peuvent alors avoir une portée différente de celle qu’elles ont avec une bonne connexion au reste du réseau. Une séparation du réseau en parties isolées complique aussi l’accord. La sécurité dépend donc de la puissance adverse, de la circulation des messages et de la vérification honnête. Les travaux Bitcoin Backbone modélisent explicitement ces conditions. Un pourcentage de puissance sans hypothèses réseau n’explique pas toute la sécurité. [4]
Les méthodes BFT (Byzantine Fault Tolerance) classiques cherchent un accord malgré des participants défaillants ou malveillants, souvent au sein d’un groupe connu à l’avance. Des exemples comme OM (Oral Messages) et PBFT (Practical Byzantine Fault Tolerance) ont leurs propres hypothèses et règles d’échange de messages. Bitcoin traite la participation ouverte par le travail et la stabilisation probabiliste de l’historique ; il ne rebaptise pas simplement ces méthodes. Choisir une branche valide plus forte ne modifie pas non plus les règles de validité. Leur évolution exige l’adoption de logiciels adaptés et de conditions compatibles. Les mineurs contribuent au choix de l’historique valide qui se poursuit, pas à imposer ce que chacun doit juger valide. [5] [6] [9]
Pour une vision complète, lisez aussi Bitcoin, Proof of Work, Difficulty Adjustment, Règles de consensus, Minage, Full Node. Cette entrée est également citée par Bit Gold, Reusable Proofs of Work, Byzantine Generals Problem, Sybil Attack.