La course de 24 heures menée par Bitcoin pour survivre à une panne mondiale d’Internet

Imaginez un effondrement, en une seule journée, de l’infrastructure fondamentale de l’Internet mondial.

Qu’il s’agisse d’une erreur humaine, d’un bug logiciel critique, d’un virus informatique incontrôlé ou d’une attaque militaire, que deviendrait Bitcoin si les points d’échange physique d’Internet qui connectent le monde s’arrêtaient soudainement ?

Si Francfort, Londres, la Virginie, Singapour et Marseille étaient simultanément hors ligne, Bitcoin serait alors divisé en trois partitions distinctes.

Le trafic traversant l’Atlantique, la Méditerranée et les principales routes transpacifiques serait interrompu, laissant les Amériques, l’Europe, l’Afrique, le Moyen-Orient, l’Asie et l’Océanie écrire leur propre histoire, indépendamment, jusqu’à la restauration des connexions.

La production de blocs se poursuit au sein de chaque partition, selon le hashrate restant accessible.

Avec une cible globale de 10 minutes par bloc, une région détenant 45 % du hashrate produira environ 2,7 blocs par heure, 35 % environ 2,1 blocs et 20 % environ 1,2 bloc. Les nœuds ne pouvant échanger ni en-têtes ni transactions entre partitions, chaque région fait progresser une chaîne valide en ignorant celles des autres.

Il en résulte une profondeur de bifurcation qui croît naturellement avec le temps et la répartition du hashrate.

La cadence imposée par la partition rend la divergence purement mécanique. Attribuons à chaque région un hashrate moyen : pour la modélisation, retenons 45 %, 35 % et 20 % comme base respective pour les Amériques, l’Asie et l’Océanie, puis l’Europe et l’Afrique.

Le groupe des Amériques ajouterait environ six blocs toutes les deux heures, l’Asie et l’Océanie quatre à cinq blocs par heure, et l’Europe et l’Afrique deux à trois blocs par heure.

Après une heure, les registres compteraient déjà plusieurs blocs de différence.

Après une demi-journée, l’écart atteindrait la centaine de blocs.

Après vingt-quatre heures, les chaînes divergeraient de plusieurs centaines de blocs, bien au-delà du champ des réorganisations habituelles, ce qui forcerait les services à considérer toute confirmation régionale comme strictement provisoire.

La profondeur potentielle de réorganisation du côté perdant augmente linéairement avec la durée d’isolement. Même une scission temporaire 50/50 crée un risque élevé.

Les mempools locaux se séparent instantanément. Une transaction émise à New York ne parviendra pas à Singapour ; les destinataires en dehors de la partition de l’expéditeur ne verront rien tant que les routes ne sont pas rétablies.

Dans chaque partition, le marché des frais devient local. Les utilisateurs rivalisent pour un espace de bloc limité avec le hashrate régional, si bien que les frais augmentent d’autant plus vite que le hashrate est faible et la demande élevée.

Les plateformes d’échange, processeurs de paiement et portefeuilles sous garde suspendent habituellement retraits et règlements on-chain dès lors que la finalité globale des confirmations disparaît. Les contreparties Lightning s’exposent alors à l’incertitude sur les transactions d’engagement validées dans les partitions minoritaires.

Dès la reprise des routes, les nœuds enclenchent une réconciliation automatique.

Chaque nœud compare les chaînes et se réorganise sur la chaîne valide cumulant le plus de travail.

Les conséquences pratiques se répartissent en trois volets :

1. La profondeur des réorganisations qui invalident les blocs des partitions minoritaires.
2. Le travail de rediffusion et de re-priorisation des transactions jusqu’alors “confirmées” sur une branche perdante.
3. Les contrôles opérationnels menés par les plateformes d’échange et dépositaires avant toute réouverture.

Après une fracture de 24 heures, plusieurs dizaines à plusieurs centaines de blocs issus de partitions minoritaires peuvent être rendus orphelins au retour, et les services ont besoin de plusieurs heures pour reconstruire les mempools, recalculer les soldes et réactiver les retraits.

La normalisation économique complète tarde souvent après la convergence protocolaire, en raison des circuits fiat, des contrôles réglementaires et de la gestion des canaux qui exigent une revue humaine.

On comprend mieux ces dynamiques en modélisant l’isolement comme un pourcentage de hashrate accessible, plutôt qu’en fonction du nombre de hubs.

Avec 30 % du hashrate isolé, la partition minoritaire produirait environ 1,8 bloc par heure. Un paiement classique à six confirmations dans cette partition devient donc risqué après environ trois heures vingt, car ces six blocs pourraient être rendus orphelins si les 70 % restants du réseau forment une chaîne plus longue.

Dans une partition quasi 50/50, les deux groupes accumulent un travail équivalent, si bien que même une brève séparation crée sur chaque rive un historique “confirmé” concurrent ; au moment de la reconnexion, le résultat devient aléatoire.

Dans une scission 80/20, la partition majoritaire l’emporte presque à coup sûr : les blocs de la minorité, soit environ 29 après une journée, seront orphelins à la fusion, annulant de nombreuses transactions dans cette zone.

Le risque de réorganisation dépend du temps et du hashrate du plus petit groupe. Le pire scénario : une partition de longue durée et presque égale.

Des outils de résilience existent et modulent l’impact réel.

Les liaisons satellites, relais radio à haute fréquence, réseaux tolérants aux délais, réseaux maillés et solutions alternatives comme les ponts Tor peuvent transporter des en-têtes ou des flux minimaux de transactions sur des routes endommagées.

Ces canaux sont étroits et à latence élevée, mais même une propagation intermittente entre partitions réduit la profondeur de bifurcation en laissant passer une fraction de blocs ou de transactions.

La diversité de peering des mineurs, l’infrastructure multi-homée des plateformes d’échange et la répartition géographique des pools augmentent la probabilité que du travail se propage globalement par des voies secondaires, limitant ainsi la profondeur et la durée des réorganisations au retour de l’infrastructure principale.

Pour les acteurs de marché, le mode opératoire en cas de fracture réseau est limpide :

• Suspendre tout règlement inter-partition, considérer chaque confirmation comme provisoire et renforcer les estimations de frais en cas de pics locaux.
• Les plateformes d’échange peuvent passer à l’attestation de preuve de réserves sans retraits actifs, allonger les seuils de confirmation pour intégrer le risque d’isolement minoritaire, et publier des politiques claires reliant la durée d’isolement au nombre de confirmations exigées.
• Les portefeuilles peuvent afficher des avertissements précis sur la finalité régionale, désactiver le rééquilibrage automatique des canaux et mettre en file d’attente les paiements urgents pour une rediffusion à la reprise.
• Les mineurs doivent maintenir une connectivité amont diversifiée et s’abstenir de toute intervention manuelle dérogeant à la règle de sélection de la chaîne la plus longue lors de la réconciliation.

Le protocole résiste par sa conception : reconnectés, les nœuds convergent automatiquement vers la chaîne cumulant le plus de travail.

L’expérience utilisateur, en revanche, pâtit durant la partition, car la finalité économique requiert une propagation globale constante.

Le scénario le plus critique, en cas de panne multi-hub inférieure à une journée, serait une paralysie temporaire des transactions transfrontalières, un choc de frais violent et déséquilibré, et des réorganisations majeures invalidant les confirmations régionales.

Après la restauration des liaisons, le logiciel résout le registre de façon déterministe et les services retrouvent toute leur fonctionnalité après vérifications opérationnelles.

La dernière étape consiste à rouvrir retraits et canaux, une fois les soldes et historiques cohérents sur la chaîne dominante.

Voilà le scénario récupérable. Mais si la fracture devient permanente ?

Qu’adviendrait-il de Bitcoin lors d’une Troisième Guerre mondiale ?

Que se passerait-il si les hubs évoqués en introduction ne revenaient jamais ?

Dans un tel scénario dystopique, Bitcoin tel qu’on le connaît ne renaîtrait pas.

On assisterait à des partitions géographiques permanentes fonctionnant comme des réseaux Bitcoin distincts, partageant les mêmes règles, mais sans aucune communication entre elles.

Chaque partition continuerait de miner, ajusterait sa difficulté selon son propre rythme, développerait son économie, ses carnets d’ordres et son marché des frais. Il n’existe aucun moyen de réconcilier les historiques sans rétablir la connectivité ou choisir manuellement une chaîne unique.

Voici à quoi ressemblerait un tel état stable.

Consensus et difficulté

• Jusqu’au prochain retarget de 2 016 blocs, chaque partition voit son temps de bloc varier selon le hashrate disponible. Après ce retarget, chacune retrouve un rythme de 10 minutes localement.
• Selon nos parts estimées, on attend la première re-cible de difficulté après :

Après ce premier ajustement, chaque partition produira des blocs environ toutes les 10 minutes, poursuivant ses halvings et ajustements en toute autonomie.

Sans liens océaniques, les régions nécessitent respectivement 31, 40 et 70 jours pour atteindre leur premier ajustement de difficulté.

Les dates de halving divergent (temps civil) puisque chaque région atteint ses seuils à des rythmes différents avant ce premier ajustement.

Offre et « qu’est-ce que le BTC » : frais, mempools et paiements

Dans chaque partition, le plafond de 21 millions demeure par chaîne. À l’échelle globale, le total de coins émis sur toutes les partitions dépasse 21 millions, chaque chaîne poursuivant ses propres émissions. En pratique, il en découle trois actifs BTC incompatibles, partageant adresses et clés mais avec des ensembles d’UTXO distincts.

Les clés contrôlent simultanément les coins sur toutes les partitions. Si un utilisateur dépense le même UTXO dans deux régions, ces deux transactions sont valides localement, créant des « coins scindés » à historique commun avant la scission, divergents après.

• Les mempools restent locaux définitivement. Aucun paiement inter-partition ne circule. Toute tentative de paiement vers une autre partition échoue.
• Les marchés de frais atteignent un équilibre local. La partition à faible hashrate connaît généralement une capacité plus tendue avant ajustement, puis se normalise après l’ajustement de difficulté.
• Les canaux Lightning reliant des utilisateurs de partitions différentes ne sont plus routables. Les HTLC expirent, les pairs publient leurs engagements, et les fermetures ne se valident que localement. Toute liquidité inter-partition se retrouve bloquée.

Sécurité, marchés et infrastructures

Le budget de sécurité de chaque partition équivaut à son hashrate local et aux frais perçus. Une région avec 20 % du hashrate initial présente un coût d’attaque inférieur à celui du réseau mondial. À terme, les mineurs migreront là où le prix du coin est plus élevé et l’énergie moins chère, modifiant encore le profil de sécurité.

En l’absence de chemin pour les en-têtes entre partitions, un attaquant dans une partition ne peut réécrire l’historique d’une autre ; les attaques restent confinées localement.

• Les plateformes d’échange deviennent régionales. Les tickers divergent. On voit émerger des prix BTC-A, BTC-E et BTC-X, même si chaque région se réfère toujours localement à BTC.
• Les rampes fiat, la conservation, les produits dérivés et les rails de règlement se spécialisent sur chaque chaîne régionale. Les fournisseurs d’indices et de données choisissent une chaîne par place ou publient des composites multiples.
• Les actifs bridgés et oracles dépendant de données globales deviennent inopérants ou se fragmentent en versions régionales.

Les règles du protocole restent identiques, sauf si une partition coordonne une modification. Toute mise à jour adoptée localement ne s’applique pas ailleurs, créant au fil du temps une dérive des règles.

Les logiciels de pool, explorateurs et portefeuilles fonctionnent sur des infrastructures propres à chaque partition. Les services multi-homés ne peuvent réconcilier les soldes inter-chaînes sans politique spécifique.

Les partitions peuvent-elles se réconcilier sans ces hubs ?

Si la communication n’est jamais rétablie, la convergence protocolaire devient impossible. Le seul retour à un registre unique passe par un consensus social et opérationnel, par exemple le choix coordonné de la chaîne d’une partition comme référence, et l’abandon ou la relecture des autres.

Au vu de la divergence profonde après quelques semaines, une réorganisation automatique vers un historique unique n’est pas envisageable.

Implications opérationnelles

Il faudrait traiter une fracture permanente comme un hard fork avec historique partagé avant la scission. Gérez vos clés pour dépenser les coins scindés en sécurité, évitez toute relecture inter-partitions en n’utilisant que des sorties propres à une région, et maintenez une comptabilité, des prix et des contrôles de risque distincts par partition.

Mineurs, plateformes d’échange et dépositaires doivent choisir une partition de référence, publier des identifiants de chaîne et documenter des politiques propres à chaque chaîne pour dépôts et retraits.

En somme, si ces hubs ne reviennent jamais et qu’aucun chemin alternatif ne comble la fracture, Bitcoin ne disparaît pas : il devient une constellation de Bitcoins indépendants qui ne se rejoignent plus jamais.

Avertissement :

1. Cet article est une republication de [CryptoSlate]. Tous droits réservés à l’auteur original [Liam ‘Akiba’ Wright]. Pour toute objection, contactez l’équipe Gate Learn, qui agira rapidement.
2. Avertissement : Les opinions exprimées dans cet article n’engagent que l’auteur et ne constituent en aucun cas un conseil d’investissement.
3. Les traductions dans d’autres langues sont assurées par l’équipe Gate Learn.