Aller au contenu
Financial Context Wiki

Hard fork et soft fork : compatibilité, activation et scission de chaîne

Hard fork et soft fork décrivent des relations de compatibilité différentes entre anciennes et nouvelles règles de consensus. Il faut analyser séparément ensembles de blocs valides, activation, validation des nœuds, producteurs, préparation opérationnelle, risque de rejeu et éventuelle scission de chaîne.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Hard fork et soft fork classent une modification des règles de consensus selon la façon dont les nœuds mis à niveau et anciens jugent les blocs. Soit V_old l’ensemble accepté par les anciennes règles et V_new celui des nouvelles. Un soft fork restreint la validité de sorte que V_new subset V_old : tout bloc valide selon les nouvelles règles l’est aussi selon les anciennes, mais l’ancien nœud n’applique pas la contrainte ajoutée. Un hard fork autorise au moins un bloc nouvellement valide que l’ancien nœud refuse : exists b: b in V_new and b not in V_old. Les ensembles peuvent être étendus ou incomparables ; « hard » ne signifie pas simplement bloc plus grand ou fonction plus radicale.

La compatibilité est asymétrique. Lors d’un soft fork réussi, les anciens nœuds restent sur la même chaîne car ils acceptent les blocs des producteurs à jour, mais ils peuvent accepter ce que les nouveaux refusent et offrir une assurance moindre. Lors d’un hard fork, dès qu’un producteur crée un bloc hors de l’ancien ensemble valide, les anciens nœuds ne peuvent le suivre. Si des participants économiquement importants maintiennent les deux règles, deux réseaux durables peuvent apparaître ; sans soutien effectif d’un côté, deux actifs ne subsistent pas nécessairement.

Ces termes décrivent des règles, pas la légitimité de la gouvernance, la sécurité, le soutien économique ou la méthode d’activation. Une proposition peut être qualifiée de hard fork avant activation, un changement activé peut ne pas produire de scission durable et une incompatibilité accidentelle peut diviser la chaîne sans vote. Le signal des producteurs coordonne la préparation, mais ne rend pas valide pour un nœud complet un bloc que ses règles refusent.

Ne confondez pas fork de consensus, bifurcation temporaire à règles identiques, réorganisation, fork de dépôt logiciel et mise à jour applicative. La question opérationnelle est de savoir quel réseau, quelles règles, quelle condition d’activation et quel historique reconnaît chaque nœud, portefeuille, plateforme, dépositaire, oracle et contrat.

Comment analyser un fork de protocole

  1. Fixer identité et périmètre. Noter chain, network, client version, proposition d’activation, genèse ou point de contrôle finalisé, hash actuel et couche concernée. Un même nom peut couvrir des règles différentes sur testnet, mainnet, exécution, consensus ou application.
  2. Comparer la validité de consensus. Lister chaque règle modifiée de bloc, transaction, signature, transition d’état, gas, horodatage, finalité ou fork choice. Classer des objets représentatifs valid, invalid ou unknown sous les deux versions ; les notes de version seules ne suffisent pas.
  3. Prouver la relation d’ensemble. Vérifier que tout objet nouvellement valide reste valide sous les anciennes règles. Si oui, une compatibilité soft fork est possible ; un seul bloc nouveau valide mais anciennement invalide impose à ces nœuds une transition hard fork. Tester aussi les objets anciennement valides devenus invalides.
  4. Reproduire l’activation. Vérifier hauteur, époque, temps médian, seuil de signalisation, délai de verrouillage, difficulté totale ou déclencheur de gouvernance dans la spécification et le code déployés. Signalisation, verrouillage, activation et application sont distincts.
  5. Cartographier les participants. Mesurer le poids de production mis à niveau et identifier nœuds complets, relais, portefeuilles, plateformes, dépositaires, ponts, émetteurs de stablecoins, oracles et contrats de chaque côté. Hashrate ou stake seuls ne déterminent pas l’acceptation économique.
  6. Suivre scission et transactions. Tracer hashes parents et validité sous les deux règles. Vérifier confirmations, divergence du mempool, protection contre le rejeu, adresses, identifiants de chaîne, domaines de signature, retraits et exécution sur les deux branches.
  7. Mettre en place les contrôles. Suspendre ou allonger le règlement si l’ascendance est ambiguë ; mettre à niveau et sauvegarder méthodiquement ; rapprocher soldes et passifs par branche ; tester signature et récupération hors ligne ; reprendre après des critères explicites de chaîne, nœud, contrepartie et finalité.

Cette méthode sépare quatre événements souvent regroupés sous « fork » : proposition de règle, condition d’activation, divergence observée et survie économique ultérieure d’une ou plusieurs branches. Aucun ne prouve automatiquement le suivant.

Exemples chiffrés

1. Compatibilité des ensembles valides

Supposons que les anciennes règles acceptent 100 formes de bloc et les nouvelles seulement 80. Si ces 80 appartiennent toutes à l’ancien ensemble, la relation est celle d’un soft fork ; les 20 autres formes anciennement valides sont refusées par les nœuds à jour. Ces nombres illustrent des ensembles, pas des probabilités ni des seuils de vote.

Si les nouvelles règles acceptent une forme que tous les anciens nœuds refusent, ce seul contre-exemple rompt la rétrocompatibilité, même si presque tous les autres blocs sont valides des deux côtés. La durée de la scission dépend ensuite des producteurs, utilisateurs et infrastructures.

2. L’activation de BIP 34 n’est pas la définition

BIP 34 imposait la hauteur dans la transaction coinbase et un mécanisme glissant de préparation. Avec 750 of 1,000 blocs précédents en version 2 ou plus, les nœuds rejetaient les blocs version 2 invalides ; après 950 of 1,000, ils rejetaient la version 1. Le BIP indique le bloc 227,835 comme dernier bloc version 1.

Ces seuils coordonnaient le déploiement sans définir le soft fork. La compatibilité venait de nœuds à jour plus restrictifs tandis que les anciens clients acceptaient les blocs conformes. Plus tard, BIP 9 a séparé états de déploiement et bits de version, distinguant relation de règles et mécanisme d’activation.

3. Segregated Witness comme soft fork

BIP 141 a introduit les données witness et engagé leur arbre via la transaction coinbase dans la structure existante. Les anciens nœuds pouvaient accepter les blocs conformes sans valider les nouvelles règles witness, appliquées par les nœuds à jour.

C’est une acceptation rétrocompatible, pas une vérification équivalente. Un ancien nœud peut voir les sorties régies par les nouvelles règles comme moins contraintes ; l’utilisateur qui dépend de leurs propriétés de sécurité doit valider avec un logiciel à jour. « L’ancien logiciel fonctionne encore » n’est pas une analyse de risque complète.

4. Le DAO Fork d’Ethereum

EIP-779 documente le DAO Fork au bloc mainnet 1,920,000 : une modification irrégulière d’état a transféré les soldes d’une liste L vers le contrat WithdrawDAO, sans modifier opcodes EVM, format des transactions ni structure des blocs.

Les nœuds appliquant la transition et ceux la refusant ont calculé des états différents. Un hard fork ne requiert donc ni bloc plus grand ni nouvel opcode : une règle ponctuelle de transition suffit, et un soutien persistant aux deux historiques peut préserver deux réseaux.

Risques et erreurs de contrôle

Erreurs de classification et de spécification

  • Appeler hard fork toute pointe concurrente temporaire, malgré des règles identiques et une fork choice normale qui la résout.
  • Définir tout assouplissement comme hard fork et toute restriction comme soft fork sans tester les vrais ensembles valides.
  • Assimiler rétrocompatibilité d’acceptation et sécurité complète ; les anciens nœuds n’appliquent pas les nouvelles contraintes.
  • Déduire le consensus d’une marque, feuille de route, note ou branche de dépôt plutôt que du code et des paramètres déployés.
  • Mélanger mainnet, testnet, exécution, consensus, ponts, rollups et applications.
  • Confondre proposition, publication du client, signal, verrouillage et activation.
  • Traiter le signal des producteurs comme un vote contraignant des utilisateurs, plateformes, dépositaires ou nœuds complets.

Risques de scission et de transaction

  • Supposer que l’activation garantit une scission ou que celle-ci garantit deux actifs liquides et durables.
  • Utiliser seulement la hauteur lorsque les branches peuvent avoir des blocs différents ; vérifier hashes et ascendance.
  • Envoyer pendant la scission sans vérifier rejeu, identifiants, domaines de signature et construction propre à chaque branche.
  • Créditer un dépôt sur une branche et régler passif ou retrait sur l’autre.
  • Dépendre d’un seul explorateur, RPC ou libellé de dépositaire alors que les fournisseurs peuvent diverger ou tarder.
  • Ignorer réorganisation, finalité bloquée, partition, minage minoritaire, double vote ou données indisponibles.
  • Supposer le même soutien de l’émetteur pour symbole, contrat, stablecoin, prix d’oracle ou créance de pont sur les deux branches.

Risques de gouvernance et d’exploitation

  • Présenter la compatibilité comme preuve de légitimité, décentralisation, sécurité ou soutien économique.
  • Mettre à niveau des nœuds de production sans binaires reproductibles, sauvegardes, limites de retour, test de migration et hashes indépendants.
  • Supposer qu’une rétrogradation est toujours sûre après de nouvelles données, formats de portefeuille ou conditions de slashing.
  • Déplacer des clés ou « réclamer les jetons du fork » avec un logiciel non vérifié pouvant exposer secrets ou signatures.
  • Considérer un solde instantané comme disponible sans vérifier maturité, verrous, état du contrat et politique de conservation.
  • Conclure sur fiscalité, comptabilité ou valeur avant d’établir propriété, contrôle, liquidité et règles locales.

Idées reçues

  • Un hard fork crée toujours une nouvelle monnaie. Un second actif exige production continue, utilisateurs, infrastructure et marché ; beaucoup de mises à niveau convergent vers un historique.
  • Un soft fork est sans risque puisque les anciens nœuds fonctionnent. Ils peuvent suivre la chaîne, mais n’appliquent pas la règle ajoutée et valident moins strictement.
  • Une majorité de hash ou de stake peut seule changer toute règle. Les nœuds complets refusent les blocs invalides selon leurs règles ; le poids n’agit qu’entre blocs acceptés.
  • Hard signifie conflictuel et soft unanime. Les termes classent la compatibilité, pas le consensus social, la gouvernance ou la controverse.
  • Tout fork visible dans un explorateur est une mise à niveau. Des blocs concurrents à règles identiques et des réorganisations surviennent sans changement de consensus.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...