Hard Fork vs. Soft Fork

Les forks, ou la menace qu'ils représentent, semblent être une caractéristique bien établie du paysage des Cryptomonnaie . Mais que sont-ils ? Pourquoi sont-ils si importants ? Et quelle est la différence entre un hard fork et un soft fork ?

En programmation, un « fork » est une modification de code open source. Généralement, le code dérivé est similaire à l'original, mais avec des modifications importantes, et les deux « prongs » cohabitent harmonieusement. Parfois, un fork est utilisé pour tester un processus, mais aveccrypto-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.

Tous les forks ne sont pas intentionnels. 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. Généralement, ces types de forks accidentels sont identifiés et résolus. La majorité des forks de Cryptomonnaie surviennent en raison de désaccords sur des caractéristiques intrinsèques, comme nous le verrons plus loin.

ONE est important de garder à l'esprit que les forks partagent un « historique ». L'historique des transactions sur chacune des chaînes (ancienne et nouvelle) est identique avant la scission.

Fourches dures

Il existe deux principaux types de fork de programmation :

• Fourche dure.
• Fourche souple.

Un hard fork est une modification d'unblockchainProtocole invalidant les anciennes versions. Si les anciennes versions continuent de fonctionner, elles utiliseront un protocole et des données différents de ceux de la version plus récente. Cela peut entraîner une confusion importante et des erreurs potentielles.

Avec 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 qui peuvent être ajoutées, ETC Une modification de l'une de ces règles entraînerait l'acceptation des blocs par le nouveau protocole mais leur rejet par les anciennes versions et pourrait entraîner de graves problèmes, voire une perte de fonds.

Par exemple, si lelimite de taille de blocdevaient être augmentés 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.

Supposons que ce bloc de 2 Mo soit 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 version antérieure du protocole ? Ce dernier tentera d'ajouter son bloc à la blockchain, mais détectera que le dernier bloc n'est pas valide. Il ignorera donc ce bloc et associera sa nouvelle validation à la ONE.

Soudain, vous vous retrouvez avec deux blockchains : ONEune avec des blocs de versions anciennes et récentes, et l'autre avec uniquement des blocs de versions anciennes. La croissance la plus rapide dépendra des nœuds qui valideront les blocs suivants, et des divisions supplémentaires pourraient survenir. Il est possible que les deux chaînes (ou plus) puissent croître en parallèle indéfiniment.

Il s'agit d'un hard fork, potentiellement complexe. Il est également risqué, car il est possible que les bitcoins dépensés dans un nouveau bloc soient à nouveau dépensés sur un ancien bloc (car les commerçants, les portefeuilles et les utilisateurs exécutant l'ancien code ne détecteraient pas les dépenses effectuées sur le nouveau code, qu'ils jugent invalides).

La seule solution serait d'abandonner une branche au profit de l'autre, ce qui impliquerait des pertes pour certains mineurs (les transactions elles-mêmes ne seraient pas perdues, mais simplement réaffectées). Ou alors, tous les nœuds devraient migrer simultanément vers la nouvelle version, ce qui est difficile à réaliser dans un système décentralisé et largement répandu.

Ou, les divisions 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 à renforcer les règles, à mettre en œuvre une modification esthétique ou à ajouter une fonction n'affectant en rien la structure de la blockchain, les blocs de la nouvelle version seront acceptés par les nœuds de l'ancienne version. L'inverse n'est pas vrai : la nouvelle version, plus « serrée », rejettera les blocs de l'ancienne version.

En Bitcoin, ancienne version mineurs Les mineurs se rendraient compte que leurs blocs étaient rejetés et seraient contraints de mettre à niveau. À mesure que davantage de mineurs migrent vers la dernière version, la chaîne contenant principalement de nouveaux blocs devient la plus longue, ce qui augmente le nombre de blocs orphelins d'ancienne version créés et incite davantage de mineurs à mettre à niveau. Ce processus garantit l'autocorrection du système. Puisque les blocs de nouvelle version sont acceptés par les nœuds anciens et mis à niveau, ces derniers finissent par WIN.

Par exemple, supposons que la communauté décide de réduire la taille du bloc à 0,5 Mo par rapport à sa limite théorique actuelle de 4 Mo (avecBlocs SegWit.) Les nœuds de nouvelle version rejetteraient les blocs avec l'ancienne limite et s'appuieraient sur le bloc précédent (s'il était extrait avec une version mise à jour du code), ce qui provoquerait une bifurcation temporaire.

Il s'agit d'un soft fork, et cela s'est déjà produit à plusieurs reprises. Initialement, Bitcoin n'avait T de limite de taille de bloc. L'introduction de la limite de 1 Mo s'est faite via un soft fork, la nouvelle règle étant plus stricte que l' ONE.

Le fonction de hachage pay-to-script, qui améliore le code sans en modifier la structure, a également été ajouté avec succès via un soft fork. Ce type de modification ne nécessite généralement que la mise à niveau de la majorité des mineurs, ce qui le rend plus réalisable et moins perturbateur.

Les soft forks ne comportent pas le risque de double dépense qui affecte les hard forks, puisque les marchands et les utilisateurs exécutant d'anciens nœuds liront à la fois les blocs de version nouvelle et ancienne.

Pour des exemples de changements qui nécessiteraient un soft fork, voir le «liste de souhaits de softfork".