Que signifie un soft fork dans le monde des cryptomonnaies ?

Pour la majorité des détenteurs de cryptomonnaies, une bifurcation logicielle réglementée ne crée pas de nouvelle cryptomonnaie et ne nécessite aucune action immédiate de leur portefeuille. Le principal risque réside dans le processus de coordination. Toutes les parties prenantes, y compris les mineurs , les validateurs, les opérateurs de nœuds, les portefeuilles, les plateformes d'échange et les utilisateurs, doivent s'accorder sur la mise en œuvre de règles plus strictes. L'absence d'accord pourrait entraîner une scission du réseau, même si la bifurcation est techniquement rétrocompatible.

• Qu'est-ce qu'une fourchette souple ? Il s'agit d'une mise à niveau du réseau visant à restreindre l'ensemble des règles valides tout en maintenant la compatibilité avec les nœuds existants.
• Qu'est-ce qui a changé ? Cela permet au réseau d'ajouter des règles plus strictes sans exiger que tous les participants effectuent la mise à niveau simultanément.
• Le principal danger. La fourche souple controversée pourrait entraîner le rejet de blocs, un risque de réorganisation de la chaîne, voire une scission si son activation manque de coordination.

Imaginez les règles du Bitcoin comme un grand cercle, et tout bloc à l'intérieur de ce cercle est considéré comme valide.

La bifurcation douce crée un cercle plus petit à l'intérieur de lui-même. Désormais, les nœuds mis à jour n'acceptent que les blocs situés à l'intérieur de ce cercle plus petit. Or, le point essentiel est le suivant : chaque bloc contenu dans le cercle plus petit se trouve également à l'intérieur du cercle plus grand. Par conséquent, les anciens nœuds, qui utilisent encore les règles originales, voient ces blocs mis à jour et les acceptent sans problème.

C’est le principe de la rétrocompatibilité. Les logiciels plus anciens peuvent suivre la nouvelle version sans même se rendre compte qu’un changement de règles a eu lieu.

Comme les blocs mis à jour respectent toujours les anciennes règles, le réseau n'a pas besoin de basculer complètement d'un coup. Les mineurs, les validateurs , les plateformes d'échange et les portefeuilles peuvent effectuer la mise à niveau progressivement, à condition que la production de blocs respecte les règles plus strictes avant qu'un grand nombre de blocs incompatibles ne s'accumulent.

La relation entre les règles fonctionne comme suit :

• Les anciens nœuds appliquent les règles plus générales de la pré-fourche.
• Les nœuds mis à jour appliquent les anciennes règles en plus des nouvelles restrictions.
• Les blocs conformes aux nouvelles règles respectent également les anciennes.
• Les blocs incompatibles sont rejetés par les nœuds mis à jour.
• Si une proportion suffisante du réseau produit des blocs compatibles, les anciens nœuds restent sur la même chaîne sans remarquer aucun changement.

Le mot clé est « sous-ensemble » . Une bifurcation douce (soft fork) maintient les nouvelles règles à l'intérieur des anciennes limites. Une bifurcation dure (hard fork) les dépasse complètement. Dans ce cas, les anciens nœuds examinent les nouveaux blocs de la chaîne et les rejettent d'emblée, car ces blocs enfreignent les règles qu'ils appliquent encore. Les deux ensembles se retrouvent alors sur des chaînes différentes.

Pour mieux comprendre comment le registre sous-jacent est interconnecté, il est conseillé de commencer par lire le guide « La blockchain expliquée pour les débutants ».

Pour comprendre la différence fondamentale entre les soft forks et les hard forks dans le monde des cryptomonnaies , on peut la résumer en une phrase : un soft fork renforce les règles, tandis qu’un hard fork les réécrit complètement.

Lors d'une mise à jour logicielle (soft fork), les anciens nœuds peuvent toujours vérifier les blocs sur la nouvelle chaîne. Ils ne comprennent peut-être pas tous les détails des nouvelles règles, mais ils ne rejettent pas la chaîne. En revanche, lors d'une mise à jour logicielle (hard fork), les anciens nœuds considèrent les nouveaux blocs comme invalides et restent donc sur leur propre chaîne distincte.

La différenciation du marché est également importante. Bitcoin Cash est l'exemple le plus flagrant d'un hard fork qui a perduré : un réseau distinct, un actif numérique distinct et une communauté distincte. Depuis, Ethereum a fait des hard forks planifiés sa voie de mise à niveau standard. Cependant, le fork Ethereum Classic de 2016 reste la scission la plus importante dans sa gouvernance.

Cette distinction technique se manifeste également sur les plateformes d'échange de cryptomonnaies. Lors d'une mise à jour logicielle (soft fork) sans interférence, leur priorité est de garantir le bon fonctionnement des dépôts, des retraits et de la configuration des portefeuilles. En revanche, lors d'une mise à jour logicielle majeure (hard fork), elles doivent faire face à un choix plus complexe : intégrer le nouvel actif numérique, l'ignorer ou proposer les deux cryptomonnaies aux détenteurs existants.

Aucune entité ne contrôle à elle seule le succès du Soft Fork ; celui-ci requiert la coopération de toutes les parties prenantes.

Les développeurs écrivent et vérifient le code, tandis que les opérateurs de nœuds complets définissent les règles appliquées par leurs programmes. Les mineurs produisent des blocs qui, selon qu'ils respectent ou non les nouvelles règles, sont validés. Les portefeuilles et les plateformes d'échange gèrent l'interface utilisateur. Le système ne fonctionne que si une part suffisante du réseau applique effectivement les règles plus strictes.

Pour Bitcoin en particulier, la signalisation des mineurs était le principal outil de coordination. La version BIP-9 utilise des bits dans l'en-tête des blocs pour suivre l'état de préparation sur des périodes de 2 016 blocs, soit environ deux semaines chacune. Dès qu'un nombre suffisant de mineurs signalent leur soutien pendant cette période, une période de blocage commence avant l'entrée en vigueur des nouvelles règles.

Voici ce que chaque groupe fait concrètement pendant le processus d'activation :

• Les développeurs proposent des modifications de règles, les testent et les examinent.
• Le contrat complet détermine les règles que ses opérateurs imposent à chaque bloc qu'ils reçoivent.
• Les mineurs ou vérificateurs produisent des blocs qui, soit sont conformes, soit ne le sont pas, selon les règles les plus strictes.
• Le gouverneur met à jour les flux de signature, les formats d'adresse, les outils graphiques ou le comportement d'affichage lorsqu'une modification affecte les parties du protocole destinées à l'utilisateur.
• Les plateformes d'échange gèrent les dépôts, les retraits, le nombre de confirmations et les notifications aux clients.
• Les détenteurs réguliers de cryptomonnaies patientent, vérifient la compatibilité de leur portefeuille et évitent de se précipiter sur les transactions pendant les périodes d'activation controversées.

C'est au niveau du nœud complet que les règles sont effectivement appliquées. Un mineur peut trouver un bloc, mais le nœud le rejettera s'il enfreint ses propres règles. Cette séparation est cruciale lorsque le signal du mineur et l'exécution du nœud divergent.

Les portefeuilles jouent un rôle différent, mais tout aussi fonctionnel. Ils ne valident pas chaque bloc de la chaîne, mais génèrent des adresses, des scripts et des signatures en fonction des règles existantes. Pour la plupart des utilisateurs, la mise à jour passe inaperçue jusqu'à ce qu'une mise à jour du portefeuille devienne nécessaire. Le véritable piège réside dans les fausses promesses de mise à niveau qui apparaissent lors d'activations très médiatisées, promettant des cryptomonnaies gratuites grâce à une bifurcation qui ne fait que renforcer les règles existantes.

Les mises à jour de Bitcoin n'ont pas toujours été sans heurts. Certaines ont été rapides et discrètes, tandis que d'autres ont duré des années et ont failli diviser la communauté. Mais elles ont toutes en commun la même structure de consensus : de nouvelles règles que les nœuds plus anciens peuvent continuer à suivre.

Voici ce que chaque mise à jour majeure a concrètement apporté :

• P2SH (BIP-16, 2012) : Cela permettait aux utilisateurs d'envoyer des fonds à un hachage de script au lieu d'exposer le script complet dans la sortie de la transaction. Pour les anciens nœuds, une transaction P2SH apparaissait comme une transaction standard de type « payer n'importe qui ». Pour les nœuds mis à jour, en revanche, une logique plus complexe était mise en œuvre. Résultat : les adresses multisignatures sont devenues plus courtes et beaucoup plus faciles à gérer.
• Contrôles de validation des blocs et des coefficients (BIP-34, BIP-65, BIP-66) : Trois mises à jour distinctes ont renforcé les règles concernant la hauteur des blocs dans les transactions Coinbase, les sorties verrouillées dans le temps et la tokenisation des signatures. Chacune a ajouté des critères plus stricts appliqués par les nœuds mis à jour, tandis que les anciens nœuds restaient actifs sur la chaîne.
• SegWit (BIP-141, 2017) : La mise à jour de Bitcoin la plus controversée politiquement à ce jour. SegWit a déplacé les signatures de transaction vers une structure de données distincte, libérant ainsi de l'espace dans les blocs sans augmenter leur taille maximale. Elle a corrigé la malléabilité des transactions, une faille permettant de modifier les identifiants de transaction avant confirmation, et a rendu fonctionnels pour la première fois des canaux de paiement comme le Lightning Network. Techniquement, la mise à jour a été un succès. Mais politiquement, elle a failli déchirer la communauté et a finalement conduit au hard fork de Bitcoin Cash.
• Taproot (BIP-341 et BIP-342, 2021) : Les signatures Schnorr, la confidentialité des scripts de type MAST et Tapscript ont été intégrés dans une mise à jour unique. Un portefeuille compatible Taproot permet de rendre une transaction complexe impliquant plusieurs parties identique à une simple transaction sur la blockchain avec une seule signature. Cela représente un gain significatif en termes de confidentialité et d'efficacité. L'implémentation de Taproot s'est déroulée sans encombre, mais son adoption concrète a été lente car les portefeuilles, les fournisseurs d'infrastructure et les développeurs de scripts ont tous dû effectuer la mise à jour indépendamment.
• SegWit Litecoin (2017) : Litecoin a implémenté SegWit plusieurs mois avant Bitcoin, notamment parce que sa communauté comptait moins d'acteurs aux intérêts divergents. Même mise à niveau technique, contexte politique différent, résultats plus rapides.

SegWit est un exemple à méditer. Bien que rétrocompatible au niveau du protocole, la controverse qui l'entourait – concernant la taille des blocs, les frais de minage et le contrôle du développement – ​​en a fait l'un des moments les plus litigieux de l' histoire du Bitcoin . Taproot, en revanche, représente l'autre extrémité du spectre : un large soutien, une activation en douceur et une adoption progressive. La définition technique d'un soft fork ne rend pas compte de l'ampleur du chaos politique qui en découle.

Le terme « rétrocompatible » est une description purement technique et ne constitue en aucun cas une prédiction du comportement de la communauté numérique.

Le problème est que les anciens nœuds acceptent les blocs conformes aux anciennes règles. Or, tous les blocs acceptés par un ancien nœud ne sont pas nécessairement conformes aux nouvelles règles, plus strictes. Lorsque des mineurs, qu'ils soient à jour ou non, produisent simultanément des blocs conflictuels, des forks temporaires se produisent dans la chaîne. C'est précisément ce qui s'est produit lors de la mise en œuvre du BIP-66 de Bitcoin en 2015. Le minage sans validation, où les mineurs produisaient des blocs sans les vérifier, a contribué à des forks ponctuels avant que les mineurs ne corrigent leur comportement (date de mise en œuvre des mises à jour logicielles de Bitcoin Optech).

Les mêmes conflits surgissent dans presque tous les processus d'activation controversés :

• Seuil d'activation : Si le seuil est fixé trop bas, la promotion est rapide mais laisse derrière elle une opposition importante. S'il est fixé trop haut, elle stagne indéfiniment tandis que les adversaires gagnent du temps.
• Signalisation des mineurs : Ce signal est censé indiquer que l'opération est prête, mais les mineurs peuvent l'utiliser stratégiquement pour retarder une proposition ou obtenir des concessions. Ce signal ne signifie pas que l'opération est exécutée.
• Application par l'utilisateur : Les opérateurs de nœuds complets peuvent rejeter les blocs produits par les mineurs, même si ces derniers indiquent les soutenir. C'est le principe d'une bifurcation logicielle activée par l'utilisateur : ce sont les utilisateurs, et non les mineurs, qui décident.
• Poids économique : Les plateformes d'échange, les traders, les fiduciaires et les portefeuilles déterminent sur quelle chaîne les utilisateurs peuvent effectivement dépenser leur argent. Ce poids économique détermine souvent quelle chaîne survivra en cas de concurrence entre deux versions.
• Dérive des objectifs : Modifier la règle peut résoudre un problème tout en limitant insidieusement les possibilités de conception futures. Les critiques soulèvent souvent ce point, et parfois ils ont raison.

Le BIP-110 en est un parfait exemple. Son projet propose une limitation temporaire, au niveau du consensus, de la taille de certains champs de données : une limite de 34 octets pour les nouvelles clés publiques de script (scriptPubKeys) sauf si le premier opcode est OP_RETURN, ce qui permettrait de conserver jusqu’à 83 octets valides. Ses partisans affirment qu’il s’agit d’une simple bifurcation logicielle (soft fork) qui préserve le coût total des nœuds et la concentration financière de Bitcoin. Ses détracteurs, en revanche, estiment que cette activation controversée pourrait isoler une chaîne minoritaire ou empêcher des cas d’utilisation légitimes qui n’ont même pas encore été inventés. Ces deux arguments pourraient être vrais simultanément. Toute proposition pourrait répondre à tous les critères techniques d’une bifurcation logicielle tout en présentant le risque d’une véritable scission si les acteurs économiques se positionnent de manière opposée avant même le début de l’activation.

Pour la plupart des détenteurs de cryptomonnaies , une mise à jour logicielle (soft fork) propre ne change rien à leur propriété. La chaîne mise à jour reste valide selon les anciennes règles ; les soldes de cryptomonnaies restent donc inchangés et les portefeuilles n'ont pas besoin d'intervenir immédiatement. La situation est différente lors de l'activation controversée, car l'incertitude quant à la chaîne qui sera dominante pourrait affecter la confirmation des transactions.

Il est plus important de prendre en charge le portefeuille lui-même que de faire la une des journaux à propos des forks, car les différents portefeuilles réagissent aux mises à jour à des vitesses différentes :

• Les options de portefeuilles Bitcoin varient en termes de rapidité de prise en charge des nouveaux types d'adresses, des flux de travail de signature, des outils de frais et des notifications de mise à jour.
• Les portefeuilles autonomes permettent aux utilisateurs de contrôler les programmes et les clés, mais ils leur font également porter la responsabilité de la sauvegarde et de la vérification des mises à jour.
• Les portefeuilles matériels froids sont moins sensibles aux perturbations quotidiennes liées à l'activation, mais ils nécessitent tout de même une prise en charge du micrologiciel, des applications associées ou un formatage d'adresse pour fonctionner avec les types de transactions postérieurs au fork.

Pour la plupart des utilisateurs, la liste de vérification lors de l'activation d'un soft fork est courte :

• Vérifiez si la mise à jour affecte les transmissions normales ou seulement les scripts avancés.
• Évitez de transférer de l'argent simplement parce que les réseaux sociaux prétendent proposer une nouvelle monnaie — une bifurcation logicielle ne crée pas une nouvelle monnaie.
• Vérifiez votre portefeuille et les notifications de votre plateforme d'échange avant d'effectuer des transactions importantes.
• Attendons que les activations controversées se calment avant de nous fier à des paiements peu fiables.
• Conservez vos phrases de récupération hors ligne et ne les saisissez jamais sur un site prétendant faire partie d'une mise à jour.

Une bifurcation logicielle peut modifier les transactions futures sans changer la propriété des cryptomonnaies existantes. Font exception les programmes marginaux ou les scripts avancés qui exploitent des comportements restreints par les nouvelles règles ; c’est pourquoi les développeurs de portefeuilles et les créateurs d’applications doivent faire l’objet d’un examen plus approfondi que les détenteurs passifs de cryptomonnaies.

Trois questions clés sous-tendent la plupart des discussions actuellement en cours sur la mise à niveau du réseau Bitcoin : quelles restrictions le réseau devrait-il imposer au niveau de la couche de consensus, quelles nouvelles capacités il devrait acquérir et quel niveau de consensus est réellement nécessaire avant que des règles plus strictes puissent être appliquées.

Les BIP ne sont que des propositions. Un numéro de BIP ne constitue pas une règle contraignante.

• Limites de données : Le BIP-110 s'inscrit dans ce débat. Il propose que les mineurs signalent leurs activités via le bit 4, avec un seuil d'approbation de 55 % sur une période de 2 016 blocs et une hauteur d'activation maximale inconditionnelle autour du 1er septembre 2026. Le principal argument porte sur la question de savoir si la couche de consensus Bitcoin doit surveiller les données écrites sur la chaîne et qui supporte les coûts en cas de problème.
• Préparation quantique : Le BIP-360 propose un mécanisme de paiement à la racine Merkle, un nouveau type de sortie d'arbre de script. L'objectif est de réduire la vulnérabilité à long terme aux attaques quantiques en supprimant les dépenses liées au chemin de clé privée de Taproot de cette sortie. Il ne s'agit pas d'une solution d'urgence à une menace existante, mais plutôt d'un choix de conception quant à la durée pendant laquelle Bitcoin souhaite maintenir sa sécurité avant que l'informatique quantique ne devienne véritablement dangereuse.
• Alliances : Les conventions permettraient à Bitcoin d'imposer des conditions quant à l'utilisation future de ses cryptomonnaies. Ses partisans y voient les fondements de coffres-forts, de la gestion de la congestion et de nouvelles perspectives d'expansion. Ses détracteurs, en revanche, craignent des restrictions imprévues et des litiges qui pourraient découler de sa mise en œuvre.

Avant de considérer l'une de ces propositions comme une règle valide, trois points méritent d'être vérifiés. Premièrement, la proposition est-elle encore à l'état de projet ou a-t-elle déjà atteint les phases de déploiement, d'installation ou d'activation ? Deuxièmement, affecte-t-elle les transferts de portefeuille classiques ou seulement les scripts avancés ? Troisièmement, le processus d'activation bénéficie-t-il d'un véritable soutien économique de la part des plateformes d'échange, des portefeuilles et des principaux opérateurs de nœuds, et pas seulement du soutien des développeurs ?