Un Hard Fork modifie les règles de validité des blocs ou transactions sans préserver la compatibilité avec les anciens nœuds. Pour suivre la nouvelle chaîne incompatible, un nœud doit adopter les nouvelles règles. Ni leur annonce ni une puissance de minage supérieure ne peuvent l'y contraindre.
Anna et Pavel exploitent chacun un Full Node, un ordinateur qui vérifie indépendamment les règles de Bitcoin. Anna installe un logiciel autorisant des blocs plus grands ; Pavel garde la limite initiale. Un bloc arrive : il respecte les nouvelles conditions, mais dépasse l'ancienne limite. Anna l'accepte, Pavel le rejette. Ce n'est pas une panne de connexion : leurs programmes ne s'accordent pas sur ce qui peut appartenir à l'historique commun. Voilà le sens pratique d'un Hard Fork. Le mot « mise à jour » ne convainc pas l'ordinateur de Pavel d'ignorer sa règle. Deux branches peuvent continuer si quelqu'un produit des blocs pour chacune et si des personnes les utilisent. Si les participants adoptent un seul ensemble de règles, deux réseaux actifs ne subsistent pas forcément. [1]
L'ancien nœud rejette le bloc incompatible et la branche construite dessus. Cela ne signifie pas qu'il reste bloqué pour toujours. Si les mineurs poursuivent une autre branche selon les règles initiales, il peut continuer à en accepter les blocs. Sans cette continuation, il reste au dernier bloc qu'il juge valide. Ce sont les règles de son logiciel qui comptent, pas le nombre de partisans du changement. Pour suivre la branche incompatible, son opérateur doit modifier ces règles délibérément. [1]
Bitcoin Cash s’est séparé de Bitcoin à la hauteur de bloc 478 559, le 1er août 2017. Il a adopté des règles permettant des blocs plus grands que ceux acceptés à l’époque par les nœuds Bitcoin et a créé sa propre chaîne qui s’est poursuivie indépendamment. Les nœuds Bitcoin ont rejeté les blocs valides uniquement selon les règles de BCH, tandis que les nœuds BCH ont suivi leur propre historique valide. C’est un exemple de Hard Fork qui n’a pas remplacé Bitcoin sur place, mais a créé un réseau distinct. [3] [4]
Pensez à l’enregistrement d’une somme reçue et pas encore dépensée : Bitcoin appelle cette sortie de transaction non dépensée un UTXO. Les branches au passé commun héritent de cet enregistrement, puis le gèrent séparément. Si vous contrôlez les clés nécessaires et que les deux réseaux reconnaissent toujours cette sortie, vous pouvez généralement dépenser les coins correspondants sur chacun. Cela ne double pas leur valeur : ce sont deux actifs distincts, avec leur propre demande. Pour des fonds conservés sur une plateforme, l'attribution des coins de l'autre réseau dépend aussi de sa politique. [4] [6]
Avec des coins sur les deux branches, vous pouvez vouloir payer sur une seule. Sans protection, quelqu'un pourrait copier la transaction signée et la diffuser aussi sur l'autre, où elle pourrait être valide. C'est le risque de replay. Vérifiez donc la protection du réseau concerné et sa prise en charge par le portefeuille. Modifier sighash, les règles définissant les données couvertes par la signature, peut par exemple lier une transaction à une chaîne précise. Des adresses d'aspect différent aident à distinguer les réseaux, mais ne fournissent pas à elles seules une protection cryptographique contre le replay. [3]
L'activation est le point prévu pour commencer à appliquer les nouvelles règles. La hauteur indique la position d'un bloc dans la chaîne. Une date fixe, une hauteur de bloc ou la signalisation des mineurs peuvent coordonner les participants qui ont adopté la mise à jour, mais ne peuvent pas modifier le logiciel d’un nœud qui ne l’a pas adoptée. Si chacun des deux ensembles de règles conserve des participants économiquement importants, les deux chaînes peuvent continuer. Le plan d’activation d’un Hard Fork est donc un plan de migration comportant un risque de scission. [1]
La gouvernance désigne ici la manière dont les participants décident des changements. Un ticker est le symbole de négociation d'un actif, comme BTC ou BCH. Les développeurs peuvent publier du code, les mineurs réaffecter leur hashrate, les entreprises choisir un ticker et des règles de dépôt, et les utilisateurs choisir leur logiciel. Aucune de ces actions ne modifie à elle seule les règles utilisées par les autres nœuds pour vérifier les blocs. Une scission durable peut persister si suffisamment de participants indépendants maintiennent volontairement les deux ensembles de règles et leur accordent de la valeur ; toute modification incompatible ne crée pas nécessairement deux réseaux durablement actifs. Qualifier une branche de « mise à jour » relève d’une convention sociale, et non d’une règle de consensus. [1]
Un réseau peut se diviser sans que personne cherche à créer une nouvelle monnaie. En mars 2013, certains anciens nœuds ne parvenaient pas à traiter un bloc contenant un nombre inhabituellement élevé d’entrées de transactions. Ils atteignaient une limite de verrous de base de données, qui empêchent des opérations simultanées de modifier les mêmes données. La nouvelle version 0.8 utilisait une autre base et acceptait le bloc. Les pools de minage BTC Guild et Slush sont revenus à la version 0.7 et ont miné sur la branche acceptée aussi par les anciens nœuds. Lorsque cette branche a accumulé davantage de travail, les nouveaux nœuds l’ont rejointe à leur tour. Il s’agissait de corriger une divergence logicielle involontaire, et non de maintenir un réseau distinct comme Bitcoin Cash. [2]
Un Soft Fork renforce les règles existantes. Un bloc qui respecte les nouvelles restrictions respecte donc aussi les anciennes règles. Un ancien nœud peut l’accepter sans vérifier lui-même les restrictions ajoutées. Un Hard Fork n’offre pas cette compatibilité : un bloc accepté par le nouveau logiciel peut enfreindre les anciennes règles. Pour l’accepter, l’opérateur d’un ancien nœud doit modifier les règles de son logiciel. Un Soft Fork ne garantit pas non plus que le réseau restera uni : si des mineurs produisent un bloc qui enfreint une nouvelle restriction, anciens et nouveaux nœuds peuvent le juger différemment. [1]
Notons V(ancien) l’ensemble des blocs acceptés par les règles d’origine. Il y a Hard Fork lorsque le nouveau logiciel accepte au moins un bloc extérieur à cet ensemble, de sorte que V(nouveau) n’est pas un sous-ensemble de V(ancien). Il s’agit souvent d’élargir l’ensemble des blocs valides, mais le critère décisif est la compatibilité : si un bloc valide pour un nouveau nœud peut être invalide pour un ancien, l’ancien validateur ne peut pas suivre la nouvelle chaîne sans modifier ses règles. [1]
Chainwork mesure le travail cumulé démontré par le minage des blocs d’une branche entière. Hashrate désigne, lui, la vitesse des calculs de minage. Un nœud choisit la branche ayant le plus de travail cumulé uniquement parmi les chaînes qui respectent ses règles. Si un bloc les enfreint, davantage de travail ne le rend pas acceptable. Pavel, dans l’exemple du début, n’acceptera donc pas un bloc trop grand simplement parce que la majorité des mineurs construisent dessus. Proof of Work peut départager des branches valides ; il ne peut pas choisir les règles à la place de l’opérateur du nœud. [1]
Commencez par vérifier le réseau, le portefeuille pris en charge et la protection contre le replay. Un nom familier ou une adresse similaire ne suffit pas. Ne saisissez pas votre Seed Phrase, les mots de récupération du portefeuille, dans un service inconnu promettant de récupérer des coins issus du fork. Avec votre propre nœud, vous pouvez aussi vérifier la version du logiciel, les nœuds connectés, le dernier bloc accepté et l'empreinte du bloc au point de séparation. Cette empreinte s'appelle un hash. Comparez ces informations à la documentation du réseau ; un explorateur Web ne remplace pas votre propre vérification des règles. [5] [6]
Pour une vision complète, lisez aussi Soft Fork, Règles de consensus, Full Node, Reorg, Guerre de la taille des blocs, UTXO. Cette entrée est également citée par Soft Fork, BIP (Bitcoin Improvement Proposal), Reorg, Guerre de la taille des blocs.