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.

soft fork : En quoi BIP8 et BIP9 diffèrent-ils, en quoi se ressemblent-ils ?

via BIP8

Selon BIP8, une proposition serait activée via les étapes suivantes  :

  • .
  • À chaque retargeting de difficulté, chaque nœud exécutant le code d’activation vérifie indépendamment si le seuil de signalisation a été atteint dans la période de difficulté conclue. Il existe trois transactions d’état possibles à partir de STARTED  :
  • la proposition s’installe dans l’état final FAILED à la fin de la période de signalisation
  • Si le seuil de signalisation a été atteint,
  • Si la proposition force l’activation via lockinontimeout: true et que la dernière période de difficulté de la période de signalisation est atteinte avec la proposition à l’état STARTED. Cela amène les nœuds mis à niveau à rejeter tous les blocs qui ne signalent pas qu’ils sont prêts
  • puis passe à l’état final ACTIVE. Les nœuds mis à niveau appliquent désormais les règles de soft fork sur le réseau.