Soft forks et hard forks

Curiosité

1. Pourquoi un réseau peut-il adopter des règles plus strictes sans obliger tous les nœuds à se mettre à jour en même temps ?
2. Quel changement structurel précis, en août 2017, a provoqué la séparation de Bitcoin Cash et de Bitcoin ?
3. Comment un bug logiciel, en mars 2013, a-t-il créé deux chaînes concurrentes que personne n’avait voulues ?

Explorer

1. Un soft fork resserre les règles de consensus. Les blocs et transactions valides selon les nouvelles règles, plus strictes, restent valides selon les anciennes, plus souples. Grâce à cette rétrocompatibilité, les nœuds non mis à jour continuent d’accepter la chaîne, tandis que les nœuds mis à jour appliquent les nouvelles contraintes. Tant que la majeure partie de la puissance de hachage applique les nouvelles règles, le réseau reste sur une seule chaîne ; sinon, même un soft fork peut le scinder, comme en juillet 2015.
2. Un hard fork assouplit ou modifie les règles de sorte que des structures auparavant invalides deviennent valides. Par exemple, relever la limite de taille des blocs rend acceptables des blocs plus gros. Si tous les nœuds ne se mettent pas à jour pour accepter ces nouvelles structures, le réseau se scinde en deux chaînes concurrentes aux historiques incompatibles. Cette scission s’est produite le 1er août 2017, lorsque Bitcoin Cash a adopté une taille de bloc supérieure à celle de Bitcoin.
3. Les soft forks exigent une activation soigneuse, car les mineurs qui appliquent les nouvelles règles doivent représenter la majorité de la puissance de hachage. Si les mineurs ignorent le signal ou appliquent des règles obsolètes, la chaîne risque malgré tout de se scinder. BIP9 (2015-2016) a standardisé l’activation par signalement des mineurs : un soft fork était verrouillé (lock-in) dès que 95 % des blocs d’une période de 2 016 blocs avaient signalé être prêts, puis, au terme d’une période supplémentaire, les nœuds mis à jour l’appliquaient.
4. Le fork accidentel de mars 2013 est survenu lorsqu’un gros bloc a été accepté par la version 0.8 mais rejeté par la version 0.7 en raison d’une limite de la base de données. Le réseau s’est scindé, et la situation n’a pas été résolue par la victoire de la chaîne la plus longue, mais par des mineurs qui sont délibérément revenus à la version 0.7, si bien que la branche compatible avec la 0.7 a dépassé l’autre. L’épisode a montré que des différences involontaires entre versions peuvent scinder le réseau et qu’en cas d’urgence, la solution peut être une décision humaine coordonnée qui l’emporte sur la question de savoir quelle branche avait le plus de travail à ce moment-là.
5. Des exemples historiques illustrent ces mécanismes. P2SH (Pay-to-Script-Hash), activé en 2012 sous forme de soft fork, a permis l’utilisation de scripts complexes tout en conservant la compatibilité avec les nœuds plus anciens. SegWit (Segregated Witness) a été activé le 24 août 2017 au bloc 481 824, en retirant les données de signature de la partie de la transaction utilisée pour calculer son identifiant, ce qui a corrigé le problème de malléabilité et augmenté la capacité. Taproot a suivi en novembre 2021, au bloc 709 632.
6. Vérifiez la scission de Bitcoin Cash sur deux explorateurs de blocs. Le bloc 478 558 est le dernier bloc commun aux deux chaînes. Consultez le bloc 478 559 sur un explorateur Bitcoin et sur un explorateur Bitcoin Cash : ce sont des blocs différents, et celui de Bitcoin Cash dépasse 1 Mo, ce que les anciennes règles de Bitcoin interdisaient. À partir de cette hauteur, chaque chaîne considère les blocs de l’autre comme invalides.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 12
• BIP16: Pay to Script Hash (2012)
• BIP141: Segregated Witness (Consensus layer) (2015)
• BIP9: Version bits with timeout and delay (2015); BIP50: March 2013 Chain Fork Post-Mortem