SOFT / HARDCOMPARAISONS SOURCÉES
Soft Fork vs. Hard Fork
Examinez les modifications des règles de validité, la compatibilité des nœuds non mis à jour et les risques d’activation ou de division du réseau.
Soft Fork durcit les règles pour que les blocs valides selon celles-ci satisfassent aussi les anciens contrôles. Hard Fork autorise aussi certains blocs rejetés auparavant. La distinction décrit la compatibilité, pas l’ampleur ni le soutien politique d’un changement.
02Les différences importantes
Les nouvelles règles excluent certains blocs auparavant permis. Un bloc qui les respecte reste compatible avec les anciennes.
Les nouvelles règles admettent au moins certains blocs auparavant invalides. Un ancien nœud les rejette même avec beaucoup de travail cumulé.
Il peut suivre une chaîne compatible, mais ne vérifie pas les nouvelles restrictions. Pour SegWit, par exemple, il ne valide pas les données witness.
Sans changer ses règles, il ne peut valider et accepter des blocs nouvellement permis mais auparavant interdits ; il peut rester sur une autre branche ou ne plus avancer.
Il applique les règles supplémentaires une fois les conditions d’activation remplies. La signalisation ne remplace pas la validation effective.
Il applique le nouvel ensemble de règles selon son activation. Mettre à jour un nœud ne change pas les règles des autres participants.
Des désaccords sur l’activation ou l’application peuvent produire des branches distinctes. La rétrocompatibilité seule ne garantit pas une transition fluide.
Une scission durable survient si différents groupes maintiennent des chaînes incompatibles. Le nom du changement ne garantit pas deux réseaux viables.
Un BIP décrit une proposition, pas une approbation automatique. BIP9 distingue notamment signalisation, verrouillage de l’activation et règles actives.
Publier un BIP n’active rien ici non plus. Les opérateurs doivent connaître les règles précises de transition et les conséquences de l’incompatibilité.
Soft Fork ne garantit pas l’absence de scission, et Hard Fork ne crée pas automatiquement une nouvelle monnaie. Le résultat dépend de l’activation, de l’application et du maintien d’historiques incompatibles par différents groupes.
Nous comparons les changements de consensus, pas les mises à jour ordinaires d’interface ou de politique mempool. BIP9, BIP16 et BIP141 sont des exemples précis ; leurs conditions d’activation ne sont pas universelles.