La nuit où Bitcoin a eu deux histoires valides

Le bloc 225 430 n'a pas été créé dans le but de diviser le réseau. Cependant, il contenait plus d'entrées de transaction que les blocs précédents, et a ainsi chargé la base de données d'une manière qui a révélé la différence entre les versions. Bitcoin 0.8 utilisait LevelDB et a traité le bloc. La version 0.7 avec Berkeley DB a rencontré un nombre de verrous et s'est terminée par une erreur.

Le résultat était dangereusement peu visible. Les deux groupes de nœuds ont respecté les règles comme leur programme pouvait les exécuter. La branche la plus récente n'était pas frauduleuse selon les règles de consensus intentionnelles, et les nœuds plus anciens n'ont pas été attaqués. Le réseau s'est divisé en raison d'une limite pratique non documentée d'une technologie de base de données.

Les mineurs avec la version 0.8 ont construit sur le nouveau bloc. Les mineurs avec les versions plus anciennes ont continué à partir de son prédécesseur. Une fois que les deux branches ont obtenu des blocs supplémentaires, un paiement confirmé sur l'une n'a pas besoin d'exister sur l'autre. L'utilisateur ne pouvait pas se fier de manière sécurisée au nombre habituel de confirmations, jusqu'à ce qu'il soit clair quelle histoire l'accepterait la majorité économique.

La branche la plus récente a initialement porté environ soixante pour cent de la puissance de calcul. Dans des circonstances normales, la chaîne avec la plus grande quantité de travail cumulé aurait gagné. Cependant, les nœuds plus anciens ne pouvaient pas accepter le nouveau bloc sans tenir compte de son travail. La réorganisation elle-même n'a pas pu combler le bloc que le logiciel de validation local considérait comme non valide.

L'incident a ainsi révélé la limite d'une règle simple « la chaîne la plus longue gagne ». Plus précisément, la chaîne gagne avec la plus grande quantité de travail parmi celles que le nœud reconnaît d'abord comme valides. Lorsque les nœuds ne sont pas d'accord sur la validité, le taux de hachage seul ne suffit pas pour une unification immédiate.

Les développeurs ont remarqué le problème lorsqu'ils ont commencé à différer les hauteurs et les hachages des nœuds suivis. La communication s'est concentrée sur le canal IRC, où il était possible de comparer les journaux, la puissance des branches et les réactions des grands pools. Gavin Andresen a plus tard décrit la chronologie et les décisions prises pendant la nuit dans le BIP 50.

Il n'y avait pas de choix entre une branche purement correcte et une branche clairement mauvaise. Le soutien à la version 0.8 aurait maintenu la chaîne avec la plus grande quantité de travail, mais aurait coupé une quantité de nœuds plus anciens. Le retour à la branche 0.7 signifiait convaincre les nouveaux mineurs d'abandonner les blocs qu'ils avaient déjà légitimement extrait et pour lesquels ils attendaient une récompense.

La raison pratique pour revenir en arrière était la compatibilité. La version 0.8 pouvait accepter les petits blocs créés pour la branche plus ancienne, tandis que les nœuds 0.7 ne pouvaient pas accepter le bloc problématique de la nouvelle branche. Si la puissance de calcul se déplace vers la branche acceptable pour les deux groupes, le réseau peut se réunifier sans mise à niveau immédiate et forcée de tous les nœuds plus anciens.

La décision n’était pas un ordre qu’Andresen pouvait transmettre par le protocole. Les développeurs ont contacté les opérateurs de pools pour leur expliquer la situation. Les plateformes d’échange ont reçu la recommandation de suspendre les dépôts. Bitcoin.org a publié un avertissement et demandé aux grands pools de revenir à l’ancienne version du logiciel pour réunir le réseau sur une branche compatible.

Cette coordination a été rapide parce que le cercle des principaux participants était encore relativement petit et que les gens se connaissaient des canaux publics. La rapidité a aidé à sauver le réseau d'une division plus longue, mais a également montré les liens sociaux sur lesquels le fonctionnement précoce dépendait. Bitcoin n'avait pas de chef ; il avait cependant des personnes dont l'appel téléphonique ou le message pouvaient déplacer une grande partie de la puissance de calcul.

La discussion sur IRC n'avait aucune force juridique ni clé d'administration secrète. Son importance résidait dans le fait qu'elle réunissait en un seul lieu des personnes dotées de capacités d'intervention différentes. Les développeurs savaient expliquer la cause, les pools pouvaient rediriger le hashrate, les bourses suspendre les dépôts et les opérateurs de nœuds changer de version. Chaque mesure comportait son propre risque et personne ne pouvait garantir que les autres suivraient. La décision de soutenir la branche compatible avec la version 0.7 n'était donc pas un ordre technique émanant du centre du réseau, mais un pari coordonné que cette voie permettrait de rétablir le plus rapidement l'historique commun avec le moindre impact sur les utilisateurs. Le succès ne peut être dissocié de la petite taille de la communauté à l'époque ni présenté comme une procédure universelle de gestion de crise.

La décision déterminante est venue de BTCGuild, dirigé par Michael Marsee, connu sous le pseudonyme Eleuthria, et de Slush Pool, le pool de Marek Palatinus. Les deux opérateurs sont revenus de la version 0.8 à la version 0.7 et ont dirigé leur puissance de calcul vers l’ancienne branche. Ils ont ainsi contribué à faire basculer le rapport entre les quantités de travail accumulées sur les deux chaînes.

Il ne s'agissait pas d'un geste gratuit dans le tableau. Les blocs extraits sur la branche abandonnée ont cessé de faire partie de la chaîne principale lors de la réorganisation, donc leurs récompenses n'auraient pas dû rester utilisables. Le BIP 50 rappelle explicitement que les pools ont sacrifié une somme d'argent importante pour que le réseau revienne à une branche commune.

Une fois que la branche plus ancienne a pris les devants, les nœuds 0.8 mis à jour ont pu l'accepter et réorganiser leur histoire. Les anciens nœuds étaient déjà sur celle-ci. La division s'est terminée non pas parce que l'une des versions a éloignement réécrit l'autre, mais parce que suffisamment de mineurs ont créé plus de travail au-delà du point que les deux pouvaient vérifier.

Pendant l'incident, il y a eu au moins une grande double dépense, décrite comme une expérience, et non comme une attaque planifiée. L'événement a néanmoins montré un risque réel : une transaction pouvait être confirmée sur une branche qui serait plus tard abandonnée. La recommandation d'arrêter les dépôts n'était pas une panique ; elle protégeait les services des soldes comptables basés sur une histoire temporaire.

Les pools à ce moment-là ne possédaient pas le réseau. Ils pouvaient influencer l'ordre des blocs avec la puissance de calcul que les mineurs leur avaient confiée, mais ils ne pouvaient pas forcer chaque nœud complet à accepter des règles arbitraires. Leur succès dépendait d'un objectif étroit : créer une branche que les nœuds anciens et nouveaux considéraient comme valide, et lui donner le plus de travail.

Gavin Andresen a ensuite décrit l’incident dans le BIP 50. Le document ne prétend pas que le réseau a fonctionné sans défaut. Il explique la cause, le déroulement des événements, les blocs perdus, la double dépense et les mesures destinées à détecter plus tôt des divergences similaires. La publication de cette analyse a permis de transmettre l’expérience de cette nuit de crise au-delà des seuls participants. D’autres développeurs ont pu en tirer des leçons.

L'une des leçons était que le consensus ne comprend pas seulement les règles écrites dans un commentaire ou une documentation. Le comportement pratique d'un programme largement déployé peut devenir une limitation du réseau, même si personne n'a l'intention qu'il ait une signification monétaire. La migration de la base de données ne doit donc pas être considérée comme un changement purement interne, si elle peut modifier l'acceptation d'un bloc.

Une autre leçon était la nécessité de coordonner les mises à niveau de manière plus prudente et de tester les blocs près des limites opérationnelles. La version 0.8 a apporté une amélioration des performances, mais la différence s'est manifestée dans la chaîne réelle. Après l'incident, les développeurs ont introduit des limites temporaires et ont préparé un chemin qui a permis aux anciennes dépendances d'être plus tard abandonnées en toute sécurité.

L'histoire est parfois utilisée comme preuve que Bitcoin est contrôlé par quelques développeurs, et parfois comme preuve qu'il est automatiquement indestructible. Aucune de ces versions abrégées n'est exacte. Les gens ont pu coordonner de manière urgente la réparation, mais ils ont eu besoin de la coopération des pools, des bourses et des opérateurs de nœuds. Le logiciel a décidé sur chaque ordinateur individuel, et le résultat commun est né de leur combinaison.

La nuit du 11 au 12 mars s’est achevée avec une seule chaîne principale, mais les divergences ne s’étaient pas effacées d’elles-mêmes. Certains participants avaient donné l’alerte, d’autres suspendu des services, et les mineurs avaient renoncé au travail déjà accompli pour retrouver un historique compatible. Bitcoin a surmonté ses deux passés concurrents grâce aux règles, aux coûts économiques assumés et à des personnes prêtes à reconnaître que, cette fois, le logiciel le plus récent devait céder.

Le BIP 50 est précieux parce qu’il ne referme pas l’incident sur une proclamation de victoire de la décentralisation. Il consigne la cause précise, la chronologie, le travail perdu et les mesures prévues pour éviter une nouvelle surprise. Cet échec gênant devient ainsi une base pour de futurs tests. Une question reste ouverte : combien d’hypothèses implicites séparent deux versions d’un programme que nous jugeons compatibles ? Le consensus ne se réduit pas à une liste de règles sur le papier. Des implémentations et des nœuds indépendants doivent parvenir au même résultat, même dans les cas limites. L’importance de cet accord apparaît le plus nettement lorsqu’il se rompt.