Hard forks VS Soft Fork ? La bataille
⌚: 3 minutes
Mais qu’est-ce que c’est ? Pourquoi sont-ils si important? Et quelle est la différence entre une Hard Forks et une Soft Forks ?
Un « fork », en termes de programmation, est une modification de code open source. Habituellement, le code est similaire à l’original, mais avec des modifications importantes. Parfois, un fork est utilisé pour tester un processus, mais avec les cryptomonnaies, il est plus souvent utilisé pour implémenter un changement fondamental, ou pour créer un nouvel actif avec des caractéristiques similaires (mais pas égales) à celles de l’original (Litecoin VS Bitcoin)
Toutes les fourches ne sont pas intentionnelles. Avec un code source ouvert largement répandu, un fork peut se produire accidentellement lorsque tous les nœuds ne répliquent pas les mêmes informations par exemple. En général, ces forks sont identifiées et résolues automatiquement, et la majorité des forks de crypto-monnaie sont ainsi traités.
Une chose à garder à l’esprit avec les forks est qu’elles ont une «histoire commune». L’enregistrement des transactions sur chacune des chaînes (anciennes et nouvelles) est identique avant la scission.
Hard Forks
Il existe deux principaux types de forks de programmation: hard et soft.
Un hard fork est un changement de protocole qui rend les anciennes versions invalides. Si les anciennes versions continuent à fonctionner, elles se retrouveront avec un protocole différent et avec des données différentes de celles de la nouvelle version. Cela peut entraîner une confusion importante et des erreurs possibles.
Avec bitcoin, il faudrait une mémoire trés importante pour modifier les paramètres tels que la taille du bloc, avec la difficulté du casse-tête cryptographique à résoudre, les limites des informations supplémentaires pouvant être ajoutées, etc. faire accepter les blocs par le nouveau protocole mais les rejeter par les anciennes versions ce qui entraînera de graves problèmes, voire une perte de fonds.
Par exemple, si la limite de taille des blocs passait de 1 Mo à 4 Mo, un bloc de 2 Mo serait accepté par les nœuds exécutant la nouvelle version, mais rejeté par les nœuds exécutant l’ancienne version.
Disons que ce bloc de 2 Mo est validé par un nœud mis à jour et ajouté à la blockchain. Que faire si le bloc suivant est validé par un nœud exécutant une version plus ancienne du protocole ?
Il essaiera d’ajouter son bloc à la blockchain, mais il détectera que le dernier bloc n’est pas valide. Donc, il va ignorer ce bloc et attacher sa nouvelle validation à la précédente. Tout à coup, vous avez deux chaînes de blocs, une avec les blocs de version les plus anciens et un avec les plus récents. La chaîne qui croît le plus rapidement dépendra des nœuds qui obtiendront la validation des blocs suivants, et il pourrait en résulter des divisions supplémentaires. Il est possible que les deux chaînes (ou plus) puissent croître en parallèle indéfiniment, ce qui posserait alors un probléme de fond…
Ceci est une Hard Forks, et elle est potentiellement chaotique. C’est aussi risqué, car il est possible que les bitcoins dépensés dans un nouveau bloc puissent être réutilisés sur un ancien bloc (les commerçants, les portefeuilles et les utilisateurs exécutant le code précédent ne détectant pas les dépenses du nouveau code, qu’ils jugent invalide).
La seule solution est d’abandonner une des deux versions au profit de l’autre, ce qui implique la perte de certains mineurs (les transactions elles-mêmes ne seraient pas perdues, elles seraient simplement réaffectées). Ou bien, tous les nœuds devraient passer en même temps à la nouvelle version, ce qui est difficile à réaliser dans un système décentralisé et distribué.
Ou, Bitcoin se divise, ce qui est arrivé (bonjour, bitcoin cash).
Soft Forks
Une soft fork peut toujours fonctionner avec les anciennes versions.
Si, par exemple, un protocole est modifié d’une manière qui resserre les règles, qui implémente une modification esthétique ou ajoute une fonction qui n’affecte pas la structure de quelque manière que ce soit, alors les anciens blocs de version acceptent les nouveaux blocs de version. Pas l’inverse, cependant: la version plus « récente » rejetterait les anciens blocs.
Dans bitcoin, idéalement, les mineurs de l’ancienne version réaliseraient que leurs blocs ont été rejetés et se mettraient à jour. À mesure que de plus en plus de mineurs se mettent à jour, la chaîne avec de nouveaux blocs devient la chaine la plus longue, ce qui aggraverait les anciens blocages des versions orphelines, ce qui entraînerait une mise à niveau accrue des mineurs et une correction automatique du système. Étant donné que les nouveaux blocs sont acceptés par les nœuds anciens et mis à niveau, les nouveaux blocs de version finissent par gagner, car plus longs et nombreux, c’est eux qui se répandraient sur les noeuds et les anciens se mettraient à jour.
Par exemple, disons que la communauté a décidé de réduire la taille des blocs à 0,5 Mo par rapport à la limite actuelle de 1 Mo. Les nouveaux noeuds de version rejetteraient les blocs de 1 Mo et se baseraient sur le bloc précédent (s’il était miné avec une version mise à jour du code), ce qui provoquerait un fork temporaire.
Ceci est une Soft Fork, et c’est déjà arrivé plusieurs fois. Au départ, Bitcoin n’avait pas de limite de taille de bloc. L’introduction de la limite de 1 Mo se faisait par le biais d’un «soft fork», puisque la nouvelle règle était «plus stricte» que l’ancienne. La fonction de pay-to-script-hash, qui améliore le code sans changer la structure, a également été ajoutée avec succès via un soft fork. Ce type d’amendement n’exige pas ,généralement, que la majorité des mineurs mette a jour leur bloc. Remarquez que dans l’exemple 2 il s’agit de règles plus strictes alors que dans le hard forks il s’agissaient d’ajouter une règle plus large qui est une hard fork !
