Un soft fork est une mise à jour rétrocompatible des règles de consensus d'un protocole blockchain. L'ensemble des blocs valides selon les nouvelles règles est un sous-ensemble strict de ceux valides selon les anciennes règles. Concrètement, cela signifie que les nœuds utilisant l'ancienne version du logiciel continueront d'accepter les blocs produits par les nœuds mis à jour, car ces nouveaux blocs respectent les anciennes règles – elles sont simplement plus restrictives. Contrairement à un hard fork, qui crée des types de blocs entièrement nouveaux que les anciens nœuds rejetteraient (pouvant ainsi diviser la chaîne), un soft fork permet l'évolution du protocole sans exiger une mise à jour simultanée de tous les participants.
La rétrocompatibilité des soft forks est leur caractéristique fondamentale et leur principal avantage. Lorsqu'un soft fork est activé, les mineurs ou validateurs ayant effectué la mise à jour commencent à appliquer les nouvelles règles, plus strictes. Les nœuds non mis à jour considèrent ces blocs comme valides car ils respectent toujours les règles originales, moins contraignantes. Cependant, si un mineur non mis à jour produit un bloc qui enfreint les nouvelles règles (mais respecte les anciennes), les nœuds mis à jour le rejettent. Cela crée une asymétrie : les nœuds mis à jour appliquent un ensemble de règles plus strict, tandis que les nœuds non mis à jour sont « trompés » et acceptent les blocs plus stricts car ils ne violent pas les anciennes règles. Tant qu'une majorité de la puissance de minage (ou de la puissance de staking, dans les systèmes à preuve d'enjeu ) applique les nouvelles règles, la chaîne convergera vers l'ensemble de règles mis à jour sans se scinder.
Les soft forks sont le mécanisme privilégié pour les mises à jour du protocole Bitcoin depuis les débuts du réseau. Les principales améliorations de Bitcoin, telles que Pay-to-Script-Hash (P2SH), Segregated Witness (SegWit) et Taproot, ont toutes été implémentées sous forme de soft forks. Cette approche reflète une philosophie prudente au sein de la culture de développement de Bitcoin : les changements doivent être peu perturbateurs, rétrocompatibles et réalisables sans imposer une mise à jour simultanée à l’ensemble du réseau. En contrepartie, les soft forks sont plus limités quant aux changements qu’ils peuvent introduire : ils peuvent renforcer les règles ou ajouter de nouveaux types de transactions que les anciens nœuds interprètent comme des sorties « accessibles à tous », mais ils ne peuvent pas assouplir les règles existantes ni modifier fondamentalement la structure des blocs.
Les mécanismes permettant aux soft forks de maintenir la rétrocompatibilité reposent souvent sur des astuces techniques ingénieuses. Par exemple, SegWit a introduit un format de transaction entièrement nouveau avec une structure de données témoin. Cependant, les anciens nœuds considéraient simplement les transactions SegWit comme des dépenses provenant d'adresses « accessibles à tous » : valides selon les anciennes règles, mais avec une signification différente selon les nouvelles règles. Cette méthode d'intégration de nouvelles sémantiques au sein des cadres de règles existants est une caractéristique essentielle de l'ingénierie des soft forks, exigeant une grande ingéniosité pour implémenter des modifications complexes tout en respectant les contraintes de rétrocompatibilité.
Origine & Histoire
2010 : Le premier soft fork de facto de Bitcoin s’est produit lorsque Satoshi Nakamoto a introduit plusieurs modifications renforçant les règles du code source, notamment l’ajout des opcodes OP_NOP et la limite de taille des blocs à 1 Mo. Ces modifications ont rendu invalides des comportements auparavant valides, constituant de fait des soft forks, bien que le terme ne fût pas encore utilisé.
2012 : La BIP 16 a introduit le Pay-to-Script-Hash (P2SH), l’une des premières mises à jour logicielles (soft fork) officiellement reconnues de Bitcoin. Proposée par Gavin Andresen, la P2SH a permis l’utilisation de scripts de transaction plus complexes tout en maintenant la rétrocompatibilité grâce à l’encodage du hachage d’un script dans une adresse standard. Cette mise à jour a été activée le 1er avril 2012 et a établi de nombreux précédents quant à la coordination des soft forks de Bitcoin.
2015 : Les BIP 65 (OP_CHECKLOCKTIMEVERIFY) et BIP 66 (encodage strict des signatures DER) ont été activés par soft fork, introduisant des transactions à durée de vie limitée et une validation de signature plus rigoureuse. Ces mises à jour utilisaient le système de signalisation des mineurs « IsSuperMajority », exigeant que 950 des 1 000 derniers blocs signalent leur soutien avant leur activation.
2016 : La communauté Bitcoin a entamé un débat de plusieurs années sur la scalabilité, débat qui allait définir la relation entre les soft forks et les hard forks. La proposition SegWit (BIP 141) a été introduite comme une solution de soft fork visant à diversifier les transactions et à augmenter légèrement la capacité, tandis que des factions opposées préconisaient un hard fork pour augmenter directement la taille maximale des blocs. Ce débat a cristallisé la distinction philosophique entre soft forks et hard forks dans la culture des cryptomonnaies.
2017 : Segregated Witness (SegWit), la plus importante mise à jour logicielle (soft fork) de l’histoire de Bitcoin à l’époque, a été verrouillée le 8 août 2017, après que 100 % des mineurs aient atteint le seuil de 95 % lors d’une période de signalisation. Elle a été activée le 24 août 2017, au bloc 481 824. SegWit a séparé les données de signature des données de transaction, corrigeant ainsi la malléabilité des transactions, permettant le déploiement du Lightning Network et augmentant la capacité effective des blocs. Son activation a été catalysée par le mouvement UASF (User Activated Soft Fork), au cours duquel les opérateurs de nœuds ont menacé d’imposer SegWit indépendamment de la signalisation des mineurs.
2021 : Taproot, la prochaine mise à jour majeure de Bitcoin (soft fork), a été verrouillée le 12 juin 2021 au bloc 687 284 après avoir atteint le seuil de signalisation de 90 % des mineurs, et activée le 14 novembre 2021 au bloc 709 632. Proposée initialement par Greg Maxwell et formalisée par des BIP (British Protocols Inventory) rédigés par Pieter Wuille, Tim Ruffing, AJ Townes et Jonas Nick, Taproot a introduit les signatures Schnorr et les arbres de script alternatifs merkelisés (MAST), améliorant considérablement la confidentialité, l’efficacité et les capacités des contrats intelligents de Bitcoin. Taproot a utilisé le mécanisme d’activation « Speedy Trial » (une variante du BIP 8), atteignant le seuil de signalisation requis de 90 % des mineurs en une seule fenêtre de signalisation.
2023-2026 : La communauté Bitcoin a mené de vifs débats sur les futures soft forks potentielles, notamment les propositions OP_VAULT (BIP 345) pour une sécurité renforcée de la conservation des actifs, OP_CAT (BIP 347) pour la gestion des engagements et CTV (OP_CHECKTEMPLATEVERIFY, BIP 119) pour la création de modèles de transactions. Ces propositions ont mis en lumière la tension persistante entre la philosophie de mise à jour prudente de Bitcoin et le désir d'améliorer ses fonctionnalités.
En termes simples
Analogie avec la mise à jour du code du bâtiment : Imaginez une ville qui met à jour son code du bâtiment pour exiger des fondations plus solides pour les nouvelles constructions. Tous les bâtiments existants restent conformes à la réglementation, car ils ont été construits selon l’ancien code. En revanche, toute nouvelle construction doit respecter la norme plus stricte. Une réforme progressive fonctionne de la même manière : elle renforce les règles pour les constructions futures tout en maintenant la validité de tous les bâtiments construits selon les anciennes règles.
Analogie avec la réduction de la limitation de vitesse : Imaginez une autoroute où la limitation de vitesse passe de 70 km/h à 55 km/h. Les véhicules roulant déjà à 55 km/h ou moins sont en règle, que ce soit selon l’ancienne ou la nouvelle réglementation. En revanche, un véhicule roulant à 65 km/h enfreindrait la nouvelle réglementation, même s’il était en règle auparavant. Les nœuds mis à jour appliquent la limitation à 55 km/h ; les nœuds non mis à jour considèrent toujours que 70 km/h est une vitesse autorisée, mais ne détectent que les véhicules roulant à 55 km/h ou moins.
Analogie avec le code vestimentaire d'un restaurant : un restaurant qui n'imposait auparavant aucun code vestimentaire exige désormais une tenue « décontractée chic ». Les clients déjà en costume (qui répondent donc à la nouvelle norme) peuvent toujours entrer. Les habitués, habitués à l'absence de code vestimentaire, ne voient aucun inconvénient à voir une clientèle élégante. En revanche, toute personne se présentant en tongs se verra refuser l'entrée par le nouveau système (les serveurs mis à jour), même si les clients respectant l'ancienne règle n'auraient pas remarqué l'infraction.
Analogie avec la mise à jour logicielle : c’est comme si le système d’exploitation de votre téléphone recevait une mise à jour qui restreint l’accès à votre caméra pour certaines applications. Les applications respectueuses de la vie privée continuent de fonctionner parfaitement. Celles qui accédaient auparavant à la caméra sans autorisation sont désormais bloquées. Le téléphone continue de fonctionner avec les anciennes applications ; il applique simplement des autorisations plus strictes à l’avenir.
Important : Bien que les soft forks soient moins perturbateurs que les hard forks, ils ne sont pas sans risque. Si les mineurs sont répartis entre ceux utilisant une version mise à jour et ceux utilisant une version non mise à jour, des divisions temporaires de la chaîne peuvent survenir. De plus, les techniques de rétrocompatibilité utilisées lors des soft forks (comme le fait de rendre les nouveaux types de transactions accessibles à tous pour les anciens nœuds) peuvent engendrer des problèmes de sécurité temporaires pour les utilisateurs n'ayant pas mis à jour leur logiciel. Il est toujours recommandé de mettre à jour le logiciel de votre nœud vers la dernière version après l'activation d'un soft fork.
Caractéristiques techniques clés
Mécanisme de rétrocompatibilité
Les nouvelles règles constituent un sous-ensemble strict des anciennes règles : tout bloc valide selon les nouvelles règles est également valide selon les anciennes règles.
Les nœuds non mis à jour acceptent les blocs des mineurs mis à jour sans tenir compte de la nouvelle application de la règle.
Les nœuds mis à jour rejettent les blocs qui enfreignent les nouvelles règles, même si ces blocs seraient valides selon les anciennes règles.
Cette asymétrie signifie qu'une majorité (et non l'unanimité) de puissance de hachage ou de mise est nécessaire pour que la bifurcation réussisse.
Le modèle « tout le monde peut dépenser » permet d'encoder de nouvelles sémantiques dans des transactions que les anciens nœuds considèrent comme trivialement valides.
Mécanismes d'activation
BIP 9 (Bits de version) : Les mineurs signalent leur disponibilité en activant des bits spécifiques dans les champs de version des blocs ; l’activation se produit lorsqu’un seuil (généralement 95 %) est atteint au cours d’une période de signalisation.
BIP 8 (BIP 9 modifié avec activation forcée) : Similaire au BIP 9, mais inclut une option de « verrouillage en cas de délai d’expiration » où la mise à jour logicielle s’active indépendamment de la signalisation des mineurs après une date spécifiée – conçue pour empêcher les mineurs de bloquer indéfiniment les mises à niveau.
Essai accéléré : une variante du BIP 8 utilisée pour Taproot, donnant aux mineurs une courte période (environ trois mois) pour signaler leur soutien avec un seuil de 90 %, faute de quoi la communauté envisagerait des voies d’activation alternatives.
Soft Fork activé par l'utilisateur (UASF) : les opérateurs de nœuds et les participants économiques appliquent de nouvelles règles indépendamment de la signalisation des mineurs, en utilisant des incitations économiques pour contraindre les mineurs à se conformer – une menace bien connue lors de la période d'activation de SegWit (BIP 148).
Journée du Drapeau : Une date/hauteur de bloc prédéterminée à laquelle de nouvelles règles entrent en vigueur, indépendamment de la signalisation – le mécanisme le plus simple, mais nécessitant un large consensus social.
Comment fonctionne une fourchette souple
Les développeurs proposent une modification du protocole et rédigent une proposition d'amélioration de Bitcoin (BIP) spécifiant les nouvelles règles de consensus.
La proposition fait l'objet d'un examen approfondi par les pairs, de tests sur le réseau de test/signet et de débats communautaires pendant des mois, voire des années.
Le code implémentant les nouvelles règles est intégré au client de référence (Bitcoin Core) via un mécanisme d'activation.
Les opérateurs de nœuds et les mineurs mettent à jour leur logiciel pour inclure le nouveau code.
Les mineurs commencent à signaler leur disponibilité pour l'activation en positionnant des bits spécifiques dans les en-têtes de blocs.
Lorsque le seuil de signalisation est atteint dans un délai défini, la bifurcation logicielle se verrouille et s'active après une période de grâce.
Après activation, les mineurs améliorés produisent des blocs conformes aux nouvelles règles plus strictes.
Les nœuds non mis à jour acceptent ces blocs comme valides (rétrocompatibilité), mais les blocs enfreignant les nouvelles règles sont rejetés par la majorité des nœuds mis à jour.
Les incitations économiques encouragent les mineurs restants qui n'ont pas encore effectué la mise à jour à le faire, car leurs blocs non conformes seraient rejetés par la chaîne majoritaire.
SegWit : Anatomie d’une fourche logicielle emblématique
Séparation des données de témoin (signature) de l'identifiant de transaction, corrigeant ainsi un bug de malléabilité des transactions existant depuis longtemps.
Introduction d'une nouvelle structure de données « témoin » ajoutée aux blocs mais invisible pour les anciens nœuds (qui voient un bloc « dépouillé » dans la limite de 1 Mo).
Augmentation de la capacité effective des blocs, passant d'environ 1 Mo à environ 2 à 4 Mo en fonction de la composition des transactions (mesurée en « unités de poids » – 4 millions d'unités de poids par bloc).
L'activation des protocoles de deuxième couche comme le Lightning Network a été rendue possible grâce à l'immuabilité des identifiants de transaction.
Utilisation d'un système de « version témoin » permettant aux futures mises à jour logicielles d'ajouter de nouvelles versions de scripts (Taproot utilisait la version témoin 1).
Taproot : Mise à jour pour la confidentialité et l’efficacité
Remplacement des signatures ECDSA par des signatures Schnorr (BIP 340), permettant l'agrégation des signatures et la validation par lots
Introduction de MAST (Merkelized Alternative Script Trees) via le BIP 341, permettant de masquer les conditions de dépenses complexes sauf lorsqu'elles sont invoquées.
Les transactions multi-signatures et les contrats intelligents sont désormais indiscernables des transactions simples à signature unique sur la blockchain.
Réduction de la taille et des frais de transaction pour les scripts complexes, tout en élargissant la programmabilité de Bitcoin
Verrouillé au bloc 687 284 (12 juin 2021) et activé à l’aide du mécanisme d’essai rapide au bloc 709 632 (14 novembre 2021)
Rejoignez l'UEEx
Découvrez la plateforme de gestion de patrimoine numérique leader au monde
Pas de scission de la chaîne – la blockchain reste une chaîne unique et continue car les nœuds non mis à jour acceptent toujours les nouveaux blocs comme valides.
L'exigence de rétrocompatibilité limite considérablement les modifications qui peuvent être introduites ; les mises à niveau véritablement transformatrices peuvent nécessiter des forks durs.
Flexibilité de mise à niveau
Les participants peuvent effectuer la mise à niveau à leur propre rythme ; il n'y a pas de date limite « anniversaire » où les nœuds non mis à niveau sont déconnectés de force.
Les nœuds non mis à niveau peuvent avoir un faux sentiment de sécurité, validant des blocs qu'ils ne comprennent pas pleinement (par exemple, en traitant les sorties SegWit comme étant « accessibles à tous »).
Cohésion communautaire
Les soft forks sont généralement moins sources de divisions politiques que les hard forks, car ils n'imposent pas aux participants une décision de mise à niveau binaire.
La perception d'une moindre urgence peut entraîner une adoption lente – il a fallu environ cinq ans après l'activation de SegWit pour que l'adoption se stabilise entre 80 et 90 %.
Modèle de sécurité
L'application de la règle ne requiert qu'une majorité de puissance de hachage (et non l'unanimité), ce qui la rend possible même en cas d'opposition de certains participants.
Si le seuil de puissance de hachage majoritaire n'est pas atteint, une division temporaire de la chaîne peut se produire, avec des historiques de transactions potentiellement différents sur les chaînes mises à niveau et non mises à niveau.
Élégance technique
Des techniques d'encodage astucieuses (gestion des versions des témoins, réutilisation des opcodes NOP) permettent d'intégrer de nouvelles fonctionnalités substantielles aux cadres de règles existants.
Ces astuces d'encodage ajoutent de la complexité technique et peuvent créer une « dette technique » – des couches de solutions de rétrocompatibilité qui rendent le code source plus difficile à appréhender au fil du temps.
Expérience développeur
Des mécanismes d'activation bien établis (BIP 9, BIP 8, essai rapide) fournissent des processus structurés et testés pour coordonner les mises à niveau à l'échelle du réseau.
La conception du mécanisme d'activation est elle-même source de controverses : le débat sur l'activation de SegWit a duré plus de deux ans, notamment en raison de désaccords sur le choix entre des mécanismes activés par les mineurs ou par les utilisateurs.
Signal de gouvernance
La signalisation des mineurs fournit un indicateur mesurable de la préparation de l'écosystème, permettant des décisions d'activation basées sur les données.
Les signaux émis par les mineurs peuvent être manipulés ou retenus de manière stratégique : les mineurs peuvent bloquer les mises à jour qui réduisent leurs revenus ou modifient l’économie du minage, même si la communauté dans son ensemble soutient le changement.
Réversibilité
En principe, une bifurcation souple peut être « annulée » par une bifurcation souple ultérieure qui assouplit à nouveau les règles (bien que cela soit extrêmement rare et complexe en pratique).
L'irréversibilité des soft forks déployés en pratique signifie que des mises à jour mal conçues peuvent durablement alourdir le protocole avec des décisions de conception sous-optimales.
Gestion du risque
Risque de division de chaîne et de bloc orphelin
Si une mise à jour logicielle (soft fork) est activée sans une puissance de hachage suffisante (par exemple, si seulement 60 % des mineurs effectuent la mise à jour), le réseau peut temporairement générer deux chaînes concurrentes : l’une suivant les nouvelles règles et l’autre les anciennes. Les blocs de la chaîne minoritaire seraient alors invalidés une fois que la chaîne majoritaire aura rattrapé son retard, ce qui pourrait entraîner des annulations de transactions. Pour atténuer ce risque : utiliser des seuils d’activation élevés (90 à 95 % de signalement), mettre en œuvre des déploiements progressifs avec des périodes de signalement prolongées et garantir un large consensus au sein de l’écosystème avant l’activation. Les utilisateurs doivent attendre des confirmations supplémentaires pendant les périodes d’activation.
Vulnérabilité des nœuds non mis à niveau
Les nœuds qui ne sont pas mis à jour après l'activation d'un soft fork peuvent valider incorrectement les transactions. Par exemple, un nœud non mis à jour pourrait accepter une transaction dépensant une sortie SegWit sans vérifier les données de témoin, la considérant comme une sortie « accessible à tous ». Bien que cela ne mette pas le réseau dans son ensemble en danger (les mineurs mis à jour appliquent les règles réelles), certains utilisateurs non mis à jour pourraient être induits en erreur par des transactions que le réseau mis à jour rejetterait. Mesures d'atténuation : Mettez à jour le logiciel de votre nœud rapidement après l'activation d'un soft fork, suivez les canaux officiels pour les annonces de mise à jour et utilisez SPV (vérification simplifiée des paiements) avec les pairs mis à jour.
Litiges relatifs au mécanisme d'activation
Le choix du mécanisme d'activation peut devenir une source de conflits au sein de la communauté. L'activation signalée par les mineurs (BIP 9) peut être bloquée par une minorité de mineurs, tandis que les mécanismes activés par les utilisateurs (UASF/BIP 148) présentent un risque de scission de la chaîne en cas d'erreur d'appréciation du consensus économique. La controverse autour de l'activation de SegWit a démontré que les désaccords concernant les mécanismes d'activation peuvent monopoliser le débat public pendant des années. Pour atténuer ces problèmes : il est essentiel de construire un large consensus social avant de proposer une activation, d'impliquer rapidement tous les acteurs concernés (mineurs, opérateurs de nœuds, plateformes d'échange, développeurs de portefeuilles) et d'utiliser des périodes d'activation limitées dans le temps (modèle d'essai rapide) afin d'éviter les retards indéfinis.
Complexité technique et bogues d'implémentation
Les contraintes de rétrocompatibilité des soft forks nécessitent des techniques d'encodage complexes susceptibles d'introduire des bogues subtils. L'interaction entre les nouvelles règles de soft fork et la logique de consensus existante doit être testée de manière exhaustive. Un bogue dans l'implémentation d'un soft fork pourrait entraîner des défaillances de consensus, des scissions de la chaîne ou des failles de sécurité. Mesures d'atténuation : examen approfondi par les pairs (les propositions de soft fork de Bitcoin Core font généralement l'objet d'un examen de 12 à 24 mois), suites de tests détaillées incluant le fuzzing, déploiement sur le réseau de test et le signet avant le réseau principal, et activation progressive avec des périodes de surveillance.
Impact économique et commercial
L'activation d'un soft fork peut engendrer de l'incertitude sur le marché, notamment en cas de désaccord au sein de la communauté quant à la mise à jour. Le débat autour de SegWit en 2017 a coïncidé avec une forte volatilité du prix du Bitcoin et a finalement conduit au hard fork Bitcoin Cash (par la faction opposée). Même les soft forks réussis peuvent provoquer des perturbations de marché à court terme, le temps que les participants évaluent les conséquences. Mesures d'atténuation : communication claire sur l'objectif et le calendrier de la mise à jour, coordination des plateformes d'échange et des fournisseurs de portefeuilles pour une transition en douceur, et éviter les transactions basées uniquement sur des spéculations liées au fork.
Pertinence culturelle
Les soft forks occupent une place particulière dans la culture et la philosophie de gouvernance de Bitcoin. Ils incarnent l'approche prudente du réseau en matière d'évolution du protocole : l'idée que les changements doivent être le moins perturbateurs possible, rétrocompatibles et réalisables par un large consensus plutôt que par une décision imposée d'en haut. Cette philosophie reflète les valeurs fondamentales de Bitcoin que sont la décentralisation et la souveraineté individuelle : aucune entité ne doit pouvoir contraindre les participants à effectuer une mise à jour, et le réseau doit continuer de fonctionner pour ceux qui choisissent de ne pas le faire.
L'épisode de l'activation de SegWit (2015-2017) a marqué un tournant dans l'histoire culturelle du Bitcoin. Il a opposé les « petits bloqueurs », partisans du soft fork SegWit, aux « gros bloqueurs », qui souhaitaient un hard fork pour augmenter la taille des blocs. Le débat n'était pas qu'une simple question technique : il s'agissait d'une véritable guerre par procuration autour de l'identité, de la gouvernance et de l'avenir du Bitcoin. L'activation finale de SegWit, grâce à la pression de la communauté et au mouvement UASF, a établi un précédent : les utilisateurs et les opérateurs de nœuds du Bitcoin, et non plus seulement les mineurs, exercent une influence considérable sur les règles du protocole. L'idée que « les opérateurs de nœuds détiennent le véritable pouvoir » demeure un pilier de la culture de gouvernance du Bitcoin.
Le mouvement UASF, symbolisé par la campagne BIP 148 et ses mèmes associés, a démontré que l'activation d'un soft fork relève autant de la coordination sociale que de la technique. Ce mouvement est lié au slogan « No2x » (en opposition au compromis SegWit2x) et a montré qu'une communauté motivée d'opérateurs de nœuds pouvait inciter les mineurs à activer une mise à jour en menaçant d'invalider les blocs non signalisants.
L'activation relativement fluide de Taproot en 2021, grâce au mécanisme d'essai rapide, a été perçue par de nombreux membres de la communauté comme une étape importante dans la maturation du processus de gouvernance de Bitcoin. Les leçons tirées des conflits autour de SegWit ont permis d'adopter une approche plus rationalisée, même si les débats concernant les futures propositions de soft fork (OP_CTV, OP_CAT, OP_VAULT) continuent de mettre à l'épreuve la capacité de la communauté à parvenir à un consensus sur les modifications du protocole. L'importance culturelle des soft forks dans Bitcoin dépasse leur simple fonction technique : ils constituent un mécanisme essentiel permettant à la communauté de gérer la tension entre innovation et stabilité.
Rejoignez l'UEEx
Découvrez la plateforme de gestion de patrimoine numérique leader au monde
Exemple 1 : Activation de Segregated Witness (SegWit) – Bitcoin
Scénario : Bitcoin a rencontré un problème de malléabilité des transactions empêchant la construction fiable de canaux de paiement (nécessaires au Lightning Network) et entraînant une augmentation du nombre de transactions non confirmées, les blocs atteignant systématiquement la limite de 1 Mo. Une augmentation de capacité était urgente, sans pour autant scinder le réseau.
Mise en œuvre : SegWit (BIP 141) a été conçu comme une bifurcation logicielle (soft fork) séparant les données de témoin des identifiants de transaction, corrigeant ainsi la malléabilité et augmentant la capacité effective des blocs grâce à une nouvelle métrique, le « poids des blocs ». Après de longs débats et la menace d’une bifurcation logicielle activée par l’utilisateur (UASF via le BIP 148), les mineurs ont atteint le seuil de signalisation de 95 % le 8 août 2017, et SegWit a été verrouillé. L’activation a eu lieu au bloc 481 824 le 24 août 2017.
Résultat : SegWit a été activé avec succès sans division de la chaîne sur le réseau Bitcoin (bien que des opposants aient par la suite créé Bitcoin Cash via un hard fork). La malléabilité des transactions a été corrigée, permettant ainsi au Lightning Network de passer du stade expérimental à un réseau gérant un volume de paiements significatif. En 2026, environ 85 à 90 % des transactions Bitcoin utilisaient au moins une entrée SegWit. Cette mise à niveau a démontré que les soft forks controversés pouvaient être résolus grâce à une combinaison de mérite technique, de pression économique et de coordination communautaire.
Exemple 2 : Activation de Taproot – Bitcoin
Scénario : Les capacités de programmation de Bitcoin étaient limitées, les transactions complexes à signatures multiples et les contrats intelligents étaient coûteux et compromettants pour la confidentialité (exposant l’intégralité du script sur la blockchain), et l’agrégation des signatures ECDSA était difficile. Une mise à niveau était nécessaire pour améliorer la confidentialité, l’efficacité et la programmabilité.
Mise en œuvre : Taproot (BIP 340, 341, 342) a combiné les signatures Schnorr, MAST et une nouvelle version de script (témoin v1) dans une seule mise à jour logicielle. Grâce au mécanisme d’activation « Speedy Trial » (une période de signalisation limitée dans le temps), les mineurs ont atteint le seuil de signalisation de 90 %, validant ainsi la mise à niveau le 12 juin 2021, au bloc 687 284. Taproot a ensuite été activé au bloc 709 632 le 14 novembre 2021, après une période de grâce d’environ cinq mois pour la préparation de l’écosystème.
Résultat : L’activation de Taproot s’est déroulée de manière remarquablement fluide comparée à SegWit, sans perturbation significative du réseau. Elle a permis la mise en place de schémas multi-signatures basés sur Schnorr, identiques aux transactions à signature unique sur la blockchain, renforçant ainsi la confidentialité. MAST a permis de masquer les conditions de dépenses complexes, sauf lorsqu’elles étaient invoquées, réduisant ainsi la taille des transactions. L’adoption de Taproot a été inégale : elle a culminé à plus de 40 % des transactions début 2024 en raison de l’activité liée aux Ordinals et aux Runes, avant de se stabiliser autour de 15-20 % avec le ralentissement de cette activité spéculative.
Exemple 3 : P2SH (Pay-to-Script-Hash) – Bitcoin
Scénario : Dans les premières années du Bitcoin, l'envoi de transactions vers des scripts complexes (portefeuilles multi-signatures, contrats à durée déterminée) exigeait que l'expéditeur inclue le script complet dans la transaction, ce qui était fastidieux, coûteux et exposait publiquement les conditions de dépense avant même que les fonds ne soient dépensés.
Implémentation : La BIP 16 (proposée par Gavin Andresen en janvier 2012) a introduit P2SH comme une modification logicielle permettant aux expéditeurs de payer le hachage d'un script plutôt que le script lui-même. Le script complet n'était révélé qu'une fois les fonds dépensés. Les anciens nœuds reconnaissaient les sorties P2SH comme un type de transaction standard, assurant ainsi la rétrocompatibilité. Cette modification logicielle a été activée le 1er avril 2012.
Résultat : P2SH a considérablement simplifié l’utilisation des portefeuilles multi-signatures et des scripts complexes, devenant ainsi la base de l’écosystème multi-signatures de Bitcoin. Il a établi le modèle d’encodage des nouvelles fonctionnalités au sein de formats de transactions rétrocompatibles – un modèle que SegWit et Taproot suivront par la suite. Les adresses P2SH (commençant par « 3 ») sont devenues omniprésentes et restent largement utilisées aujourd’hui. Cette mise à jour est considérée comme l’une des soft forks les plus réussies et les plus abouties de l’histoire de Bitcoin.
Exemple 4 : Fusion d’Ethereum (Contexte de la discussion sur les Soft Forks et les Hard Forks)
Scénario : Bien que la transition d’Ethereum de la preuve de travail à la preuve d’enjeu (la fusion, septembre 2022) ait été techniquement une bifurcation dure, le processus a mis en évidence le compromis entre bifurcation douce et bifurcation dure dans un écosystème blockchain différent où les bifurcations dures constituent le mécanisme de mise à niveau standard.
Mise en œuvre : Historiquement, la culture de développement d’Ethereum privilégiait les hard forks pour les mises à jour du protocole, avec des hard forks réguliers (Istanbul, Berlin, Londres, etc.) environ tous les 6 à 12 mois. La fusion elle-même a nécessité la mise à jour de tous les nœuds – un hard fork par définition. Cela contraste avec la préférence de Bitcoin pour les soft forks, reflétant des philosophies de gouvernance différentes : Ethereum privilégie l’innovation rapide et accepte les coûts de coordination des hard forks, tandis que Bitcoin privilégie la stabilité et la rétrocompatibilité grâce aux soft forks.
Résultat : La réussite des hard forks réguliers d’Ethereum démontre que ces derniers peuvent fonctionner lorsqu’il existe un fort consensus social et une structure de leadership claire parmi les développeurs principaux. Cependant, cette approche a également engendré des scissions de la chaîne (Ethereum Classic en 2016) en cas de rupture de consensus. Le contraste entre la culture du Bitcoin, privilégiant les soft forks, et celle d’Ethereum, qui normalise les hard forks, illustre comment différentes communautés blockchain gèrent la tension fondamentale entre rapidité d’innovation et stabilité du réseau.
Tableau de comparaison
Fonctionnalité
Fourchette souple
Fourchette
Bifurcation conflictuelle (séparation de la chaîne)
Rétrocompatibilité
Oui – les nœuds non mis à niveau acceptent les nouveaux blocs comme valides
Non – les nœuds non mis à niveau rejettent les nouveaux blocs, ce qui crée une division.
Non – le réseau se divise intentionnellement en deux chaînes incompatibles.
Exigence de mise à niveau
Facultatif (mais recommandé) – les nœuds peuvent continuer à fonctionner sans mise à niveau
Obligatoire – tous les nœuds doivent être mis à niveau ou rester sur une chaîne incompatible
Les participants doivent choisir la chaîne à suivre ; aucune mise à niveau n'est « neutre ».
Continuité de la chaîne
Chaîne unique et continue (en supposant que la majorité de la puissance de hachage adopte)
Une seule chaîne en cas d'adoption unanime ; deux chaînes en cas de désaccord.
Deux chaînes permanentes par conception (par exemple, Bitcoin contre Bitcoin Cash)
Changement de direction des règles
On ne peut que renforcer les règles (réduire l'ensemble valide) ou ajouter de nouveaux types de transactions via des astuces de rétrocompatibilité.
Il est possible de durcir ou d'assouplir les règles, de modifier la structure du bloc, d'altérer les paramètres fondamentaux.
Représente un désaccord fondamental sur les règles que la chaîne devrait suivre.
Seuil d'activation
Puissance de hachage majoritaire (~51 % minimum ; généralement 90 à 95 % pour des raisons de sécurité)
Nécessite un large consensus social ; aucun seuil de signalisation formel ne peut garantir le succès
Aucun seuil – n'importe quel groupe peut créer une bifurcation à tout moment.
Généralement moins perturbateur ; peut néanmoins être source de controverses (le débat autour de SegWit a duré plus de 2 ans).
Coût de coordination plus élevé ; peut entraîner des divisions communautaires permanentes en l’absence de consensus.
Extrêmement clivant ; crée des communautés, des marques et des écosystèmes économiques concurrents
Termes connexes
Fourchette: Une mise à niveau de protocole non rétrocompatible qui exige que tous les nœuds soient mis à niveau, ce qui peut entraîner une division de la chaîne – l'équivalent d'une bifurcation logicielle.
SegWit (Segregated Witness) : la première mise à jour majeure de Bitcoin en 2017, qui a séparé les données de témoin des transactions afin de corriger la malléabilité et d'augmenter la capacité des blocs.
Taproot : une mise à jour logicielle de Bitcoin de 2021 introduisant les signatures Schnorr et MAST pour une confidentialité, une efficacité et des capacités de contrats intelligents améliorées.
BIP (Bitcoin Improvement Proposal) : Processus formel par lequel les propositions de soft fork sont documentées, examinées et normalisées pour le réseau Bitcoin.
Règles de consensus: L'ensemble des règles de validation sur lesquelles tous les participants du réseau doivent s'accorder – les soft forks modifient ces règles de manière rétrocompatible.
UASF (User Activated Soft Fork) : un mécanisme d'activation où les opérateurs de nœuds appliquent de nouvelles règles indépendamment de la signalisation des mineurs, mettant l'accent sur la souveraineté de l'utilisateur sur le contrôle des mineurs.
Signalisation des mineurs : processus par lequel les mineurs indiquent leur disponibilité pour une bifurcation logicielle en définissant des bits spécifiques dans les en-têtes de blocs, utilisé dans le cadre du BIP 9 et de l’activation de l’essai rapide.
Réseau Lightning : Un Layer 2 Un réseau de canaux de paiement rendu possible par la correction de la malléabilité des transactions apportée par SegWit, démontrant comment les soft forks peuvent libérer l'innovation au sein de l'écosystème.
Malléabilité des transactions : un bug dans la conception originale de Bitcoin où les identifiants de transaction pouvaient être modifiés sans invalider la transaction – corrigé par la mise à jour logicielle SegWit.
Signatures Schnorr : un système de signature numérique introduit dans la version logicielle Taproot qui permet l’agrégation de signatures et la validation par lots pour une efficacité et une confidentialité accrues.
Poids des blocs : une métrique introduite par SegWit qui a remplacé la simple limite de taille des blocs, mesurant les blocs en « unités de poids » pour inciter à l’adoption du nouveau format de transaction.
Merkle Tree: Une structure de données cryptographiques utilisée dans les blocs de la blockchain sur laquelle s'appuie MAST (Merkelized Alternative Script Trees) de Taproot pour une vérification efficace des scripts.
QFP
Quelle est la différence entre un soft fork et un hard fork ? Un soft fork renforce les règles de consensus, réduisant ainsi le nombre de blocs valides. Les nœuds non mis à jour acceptent toujours les nouveaux blocs car ils respectent les anciennes règles, moins contraignantes. Un hard fork, en revanche, assouplit ou modifie les règles, de sorte que les nouveaux blocs soient rejetés par les anciens nœuds, obligeant ainsi tous les utilisateurs à effectuer une mise à jour. En résumé, les soft forks sont rétrocompatibles (l'ancienne version du logiciel fonctionne), contrairement aux hard forks (l'ancienne version du logiciel ne fonctionne plus). Bitcoin privilégie les soft forks pour sa stabilité, tandis qu'Ethereum recourt régulièrement aux hard forks pour une innovation plus rapide.
Une mise à jour logicielle (soft fork) peut-elle entraîner la scission d'une blockchain en deux chaînes ? En théorie, une mise à jour logicielle ne devrait pas provoquer de scission permanente, car les nœuds non mis à jour continuent d'accepter les nouveaux blocs. Cependant, une scission temporaire peut survenir si une minorité significative de mineurs continue de produire des blocs selon les anciennes règles, enfreignant ainsi les nouvelles. La majorité ayant effectué la mise à jour abandonnera ces blocs, et la chaîne convergera vers les nouvelles règles. Une scission permanente n'interviendrait que si la communauté est fondamentalement en désaccord et que la minorité crée intentionnellement une bifurcation ; il s'agirait alors techniquement d'une bifurcation dure (hard fork) initiée par la minorité, et non d'une conséquence de la mise à jour logicielle elle-même.
Pourquoi Bitcoin privilégie-t-il les soft forks aux hard forks ? La culture de développement de Bitcoin privilégie la stabilité, la rétrocompatibilité et la réduction de la charge de coordination pour les participants au réseau. Les soft forks permettent au réseau de se mettre à jour sans que chaque nœud ne soit mis à jour simultanément, réduisant ainsi le risque de scission de la chaîne. Cette approche prudente reflète l'éthique de Bitcoin, un réseau décentralisé et sans chef, où aucune entité ne peut imposer de mises à jour. Les hard forks, qui nécessitent une participation universelle, sont perçus par de nombreux membres de la communauté Bitcoin comme plus perturbateurs et susceptibles d'entraîner des scissions conflictuelles (comme l'a démontré Bitcoin Cash en 2017).
Qu'était-ce que le soft fork SegWit et pourquoi était-il important ? Segregated Witness (SegWit), activé en août 2017, était un soft fork qui séparait les données de signature (témoin) de l'identifiant de la transaction. Cela a corrigé la faille de malléabilité des transactions (qui permettait à des tiers de modifier les identifiants de transaction), rendant possible des solutions de seconde couche comme le Lightning Network. Il a également augmenté la capacité effective des blocs grâce à l'introduction d'une métrique, le « poids des blocs ». SegWit était sans doute la mise à jour la plus importante et la plus controversée de l'histoire de Bitcoin jusqu'alors, le débat sur sa mise en œuvre ayant duré plus de deux ans.
Comment Taproot améliore-t-il Bitcoin ? Taproot (activé en novembre 2021) a introduit trois améliorations majeures via un soft fork : (1) les signatures Schnorr, plus efficaces que les signatures ECDSA et permettant l’agrégation de signatures ; (2) MAST (Merkelized Alternative Script Trees), qui permet de masquer les conditions complexes des contrats intelligents tant qu’elles ne sont pas utilisées, améliorant ainsi la confidentialité et réduisant les frais ; (3) un nouveau système de versions de scripts qui rend les transactions complexes et multi-signatures identiques aux paiements simples sur la blockchain. Ensemble, ces changements rendent Bitcoin plus privé, plus efficace et plus programmable.
Que signifie concrètement « rétrocompatible » dans le contexte d'une mise à jour logicielle (soft fork) ? La rétrocompatibilité signifie que les nœuds exécutant une version antérieure du logiciel (avant la mise à jour logicielle) peuvent continuer à participer au réseau et à valider les nouveaux blocs. Ils n'ont pas besoin de mettre à jour leur système pour rester connectés. Ceci est possible car les nouvelles règles sont plus strictes que les anciennes : tout bloc valide selon les nouvelles règles l'est automatiquement selon les anciennes. Cependant, les nœuds non mis à jour peuvent ne pas comprendre pleinement la sémantique des nouveaux types de transactions ; ils peuvent les considérer comme trivialement valides au lieu d'effectuer une validation complète. C'est pourquoi la mise à jour est toujours recommandée, même si elle n'est pas obligatoire.
Qu'est-ce qu'un Soft Fork activé par l'utilisateur (UASF) ? Un UASF est une méthode d'activation de soft fork où les opérateurs de nœuds (et non les mineurs) appliquent les nouvelles règles. Au lieu d'attendre que les mineurs signalent leur disponibilité, les opérateurs de nœuds définissent une hauteur de bloc ou une date spécifique après laquelle ils rejettent les blocs non conformes aux nouvelles règles. Cela exerce une pression économique sur les mineurs pour qu'ils se conforment, car les blocs rejetés par les opérateurs de nœuds ne peuvent pas contenir de transactions valides ni générer de frais. La menace UASF la plus connue fut le BIP 148 lors de l'activation de SegWit, largement reconnu pour avoir contribué à inciter les mineurs à signaler leur disponibilité. Les UASF illustrent le principe selon lequel, dans les systèmes de preuve de travail, les nœuds économiques – et pas seulement les mineurs – exercent une influence significative sur les règles de consensus.
Références
Documentation Bitcoin Core : « Activation du soft fork »
Répertoire des propositions d'amélioration de Bitcoin (BIP)
