Forks, ou leur menace, semblent être une caractéristique établie du paysage des crypto-monnaies. Mais que sont-ils? Pourquoi sont-ils si gros? Et quelle est la différence entre une fourchette dure et une fourchette souple?
Un «fork», en termes de programmation, est une modification de code source ouverte. Habituellement, le code forké est similaire à l'original, mais avec des modifications importantes, et les deux «broches» coexistent confortablement. Parfois, un fork est utilisé pour tester un processus, mais avec les crypto-monnaies, il est plus souvent utilisé pour implémenter un changement fondamental ou pour créer un nouvel actif avec des caractéristiques similaires (mais non égales) à l'original.
Toutes les fourchettes ne sont pas intentionnelles. Avec une base de code open-source largement distribuée, un fork peut survenir accidentellement lorsque tous les nœuds ne répliquent pas les mêmes informations. Toutefois, ces fourchettes sont généralement identifiées et résolues, et la majorité des fourchettes de crypto-monnaie sont dues à des désaccords sur les caractéristiques incorporées.
Une chose à garder à l'esprit avec les forks est qu'ils ont une «histoire partagée». L'enregistrement des transactions sur chacune des chaînes (anciennes et nouvelles) est identique avant la scission.
Fourches dures
Il existe deux types principaux de fourchette de programmation: dure et souple.
Un hard fork est une modification apportée à un protocole rendant les anciennes versions non valides. Si les anciennes versions continuent de fonctionner, elles se retrouveront avec un protocole et des données différents de ceux de la version la plus récente. Cela peut entraîner une confusion importante et une possible erreur.
Avec bitcoin, une fourchette dure serait nécessaire pour modifier les paramètres de définition tels que la taille du bloc, la difficulté du puzzle cryptographique à résoudre, la limitation des informations supplémentaires pouvant être ajoutées, etc. faire en sorte que les blocs soient acceptés par le nouveau protocole, mais rejetés par les versions antérieures, ce qui pourrait entraîner de graves problèmes, voire une perte de fonds.
Par exemple, si la limite de taille de bloc devait passer de 1 Mo à 4 Mo, un bloc de 2 Mo serait accepté par les nœuds exécutant la nouvelle version, mais rejeté par ceux 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 prochain bloc 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. Ainsi, il ignorera ce bloc et joindra sa nouvelle validation à la précédente. Soudain, vous avez deux blockchains, l’un avec les blocs de version les plus anciens et les plus récents, et l’autre avec les blocs de version les plus anciens. La chaîne qui se développe le plus rapidement dépend des nœuds pour lesquels les prochains blocs sont validés, et des scissions supplémentaires pourraient éventuellement se produire. Il est possible que les deux (ou plus) chaînes puissent croître indéfiniment en parallèle.
C’est une fourchette difficile et potentiellement désordonnée. C’est également risqué, car il est possible que les bitcoins dépensés dans un nouveau bloc soient ensuite dépensés dans un ancien bloc (car les commerçants, les portefeuilles et les utilisateurs exécutant le code précédent ne détectent pas les dépenses relatives au nouveau code, qu’ils jugent invalides).
La seule solution est qu’une branche soit abandonnée au profit d’une autre, ce qui implique la perte de certains mineurs (les transactions elles-mêmes ne seraient pas perdues, elles seraient simplement réattribuées). Sinon, tous les nœuds devraient passer simultanément à la nouvelle version, ce qui est difficile à obtenir dans un système décentralisé et largement répandu.
Ou bitcoin se divise, ce qui est arrivé (bonjour, bitcoin cash).
Fourchette souple
Une fourchette souple peut toujours fonctionner avec les anciennes versions.
Si, par exemple, un protocole est modifié de manière à resserrer les règles, à implémenter une modification esthétique ou à ajouter une fonction qui n'affecte en aucune manière la structure, 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, «plus stricte», rejetterait les anciens blocs de versions.
Dans Bitcoin, idéalement, les mineurs de l'ancienne version se rendraient compte que leurs blocs étaient rejetés et se mettraient à niveau. À mesure que de plus en plus de mineurs effectuent la mise à niveau, la chaîne avec principalement de nouveaux blocs devient la plus longue, ce qui renforcerait les anciens blocs de version orphelins, ce qui conduirait à une mise à niveau plus importante des mineurs et à l'auto-correction du système. Puisque les nouveaux blocs de version sont acceptés 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 à la limite actuelle de 1 Mo. Les nouveaux noeuds de version rejetteraient des blocs de 1 Mo et s'appuieraient sur le bloc précédent (s'il était exploité avec une version mise à jour du code), ce qui provoquerait un fork temporaire.
C’est une fourchette douce, 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 s'est faite à l'aide d'une fourchette souple, car la nouvelle règle était «plus stricte» que l'ancienne. La fonction de hachage pay-to-script-hash, qui améliore le code sans changer la structure, a également été ajoutée avec succès par le biais d'un fork. Ce type d’amendement ne nécessite généralement que la majorité des mineurs
Enregistrer un commentaire