soft fork : En quoi BIP8 et BIP9 diffèrent-ils, en quoi se ressemblent-ils ?
Les premières fourches souples avaient chacune leur propre méthode d’activation incluse dans la proposition qui reposait sur les jours fériés ou la signalisation de version de bloc. Ce dernier ne permettait qu’une seule proposition d’être considérée simultanément car il reposait sur l’incrémentation de la version en bloc.
BIP9 a proposé une norme d’activation qui permettait de considérer plusieurs propositions en même temps. Les fourches souples qui ont été activées à l’aide de BIP9 ont été coordonnées en ayant une grande majorité de préparation du signal de puissance de hachage pour la mise à niveau (traditionnellement 95%). Les mineurs sont chargés d’évaluer l’adoption de la proposition par le réseau et l’état de préparation du signal en définissant des bits spécifiques dans le champ de version de leurs blocs. Le signal de préparation des mineurs est mesuré sur la dernière période de difficulté à chaque hauteur de reciblage. Par exemple, le soft fork segwit et le soft fork CHECKSEQUENCEVERIFY qui ont activé BIP68, BIP112 et BIP113 ont utilisé l’activation basée sur BIP9.
BIP8 est une variante et le successeur de BIP9. BIP8 utilise des hauteurs de bloc plutôt que des horodatages pour délimiter la fenêtre de signalisation et offre la possibilité d’échouer ou de verrouiller la mise à niveau à la fin de la fenêtre de signalisation. Lorsque lockinontimeout: true est défini, les nœuds exécutant le code d’activation n’acceptent que les blocs qui signalent l’état de préparation dans la dernière période de difficulté avant le timeouteight. Cela force la mise à niveau à se verrouiller à la fin de la fenêtre de signalisation. En revanche, BIP9 échouait toujours après le passage de la fenêtre de signalisation sans activation, donc BIP9 fonctionnait de manière équivalente à BIP8 avec lockinontimeout : false.
via BIP8
Selon BIP8, une proposition serait activée via les étapes suivantes :
