Titres Titres
Les fourches, ou leur menace, semblent être une caractéristique établie du paysage de la crypto-monnaie. Mais quels sont-ils ? Pourquoi sont-ils si importants ? Et quelle est la différence entre un hard fork et un soft fork ?
Un « fork », en termes de programmation, est une modification de code open-source. Habituellement, le code fourchu est similaire à l’original, mais avec des modifications importantes, et les deux « volets » coexistent confortablement. Parfois, un fork est utilisé pour tester un processus, mais avec les crypto-monnaies, il est plus souvent utilisé pour mettre en œuvre un changement fondamental ou pour créer un nouvel actif avec des caractéristiques similaires (mais pas égales) à l’original.
Toutes les fourchettes ne sont pas intentionnelles. Avec une base de code open source largement distribuée, un fork peut se produire accidentellement lorsque tous les nœuds ne répliquent pas les mêmes informations. Habituellement, ces types de fourches accidentelles sont identifiées et résolues. La majorité des fourches de crypto-monnaie se produisent en raison de désaccords sur les caractéristiques intégrées, comme nous l’explorerons ci-dessous.
Une chose à garder à l’esprit avec les fourches est qu’elles ont une « histoire partagée ». L’historique des transactions sur chacune des chaînes (anciennes et nouvelles) est identique avant la scission.
Fourches dures
Il existe deux principaux types de fork de programmation :
- Fourchette dure.
- Fourchette souple.
Un hard fork est une modification d’un protocole blockchain qui rend les anciennes versions invalides. Si les anciennes versions continuent de fonctionner, elles se retrouveront avec un protocole différent et avec des données différentes de celles de la version plus récente. Cela peut entraîner une confusion importante et d’éventuelles erreurs.
Avec le bitcoin, un hard fork serait nécessaire pour modifier les paramètres de définition tels que la taille du bloc, l’algorithme de difficulté de minage, les limites des informations supplémentaires pouvant être ajoutées, etc. Une modification de l’une de ces règles entraînerait l’acceptation des blocs par le nouveau protocole mais rejeté par les anciennes versions et pourrait entraîner de graves problèmes, voire une perte de fonds.
Par exemple, si la limite de taille de bloc devait être augmentée 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 se passe-t-il si le bloc suivant est validé par un nœud exécutant une ancienne version du protocole ? Il essaiera d’ajouter son bloc à la blockchain, mais il détectera que le dernier bloc n’est pas valide. Ainsi, il ignorera ce bloc et attachera sa nouvelle validation à la précédente.
Soudain, vous avez deux chaînes de blocs, une avec des blocs de version plus anciens et plus récents, et une autre avec uniquement des blocs de version plus anciens. La chaîne qui se développera plus rapidement dépendra des nœuds qui verront les prochains blocs validés, et il pourrait y avoir des divisions supplémentaires. Il est possible que les deux chaînes (ou plus) puissent croître en parallèle indéfiniment.
C’est un hard fork, et c’est potentiellement désordonné. C’est également risqué, car il est possible que les bitcoins dépensés dans un nouveau bloc soient ensuite dépensés à nouveau sur un ancien bloc (puisque les commerçants, les portefeuilles et les utilisateurs exécutant le code précédent ne détecteraient pas les dépenses sur le nouveau code, qu’ils jugent invalide).
La seule solution est qu’une branche soit abandonnée au profit de l’autre, ce qui implique que certains mineurs soient perdants (les transactions elles-mêmes ne seraient pas perdues, elles seraient simplement réattribuées). Ou, tous les nœuds devraient passer à la version la plus récente en même temps, ce qui est difficile à réaliser dans un système décentralisé et largement répandu.
Ou, les fractionnements de bitcoin, ce qui s’est produit (bonjour, bitcoin cash).
Fourche souple
Un soft fork est essentiellement l’opposé d’un hard fork, dans lequel les modifications nouvellement implémentées restent rétrocompatibles avec les anciennes versions.
Par exemple, si un protocole est modifié de manière à resserrer les règles, à implémenter un changement cosmétique ou à ajouter une fonction qui n’affecte en rien la structure de la blockchain, alors les nouveaux blocs de version seront acceptés par les anciens nœuds de version. Pas l’inverse, cependant : la version la plus récente et « plus stricte » rejetterait les blocs de l’ancienne version.
Dans le bitcoin, les mineurs de l’ancienne version se rendraient compte que leurs blocs étaient rejetés et seraient obligés de mettre à niveau. Au fur et à mesure que de plus en plus de mineurs passent à la dernière version, la chaîne avec principalement de nouveaux blocs devient la plus longue, ce qui, à son tour, augmente la quantité de blocs d’ancienne version orphelins qui sont créés et entraîne la mise à niveau de plus de mineurs. Ce processus garantit que le système s’auto-corrige. Étant donné que les nouveaux blocs de version sont acceptés à la fois par les nœuds anciens et mis à niveau, les nouveaux blocs de version finissent par l’emporter.
Par exemple, supposons que la communauté ait décidé de réduire la taille du bloc à 0,5 Mo par rapport à sa limite théorique actuelle de 4 Mo (avec les blocs SegWit). Les nœuds de la nouvelle version rejetteraient les blocs avec l’ancienne limite et s’appuieraient sur le bloc précédent (s’il a été exploité). avec une version mise à jour du code), ce qui provoquerait un fork temporaire.
C’est un soft fork, et c’est déjà arrivé plusieurs fois. Initialement, Bitcoin n’avait pas de limite de taille de bloc. L’introduction de la limite de 1 Mo s’est faite via un soft fork puisque la nouvelle règle était « plus stricte » que l’ancienne.
La fonction pay-to-script-hash, qui améliore le code sans modifier la structure, a également été ajoutée avec succès via un soft fork. Ce type d’amendement ne nécessite généralement que la mise à niveau de la majorité des mineurs, ce qui le rend plus faisable et moins perturbateur.
Les soft forks ne comportent pas le risque de double dépense qui afflige les hard forks, puisque les commerçants et les utilisateurs exécutant d’anciens nœuds liront à la fois les nouveaux et les anciens blocs de version.
Pour des exemples de modifications qui nécessiteraient un soft fork, consultez la « softfork wishlist ».
