Un MASF est un mécanisme par lequel les mineurs de blockchain peuvent introduire de nouvelles mises à jour sans affecter son fonctionnement.
Un Fourche souple Miner Active (MASF) o fourche souple activée par mineur est un mécanisme qui, comme un UASF, génère un changement ou une transition du réseau vers un nouvel ensemble de règles de consensus. La différence de MASF avec UASF, c'est que MASF est activé par les mineurs utilisant leur puissance de hachage au lieu d'être activé par noeuds complète.
Pour l'activation de ce mécanisme, les mineurs sont tenus d'exposer ou de révéler leur volonté d'accepter des changements ou des modifications du protocole. Et pour y parvenir, les mineurs utilisent leur pouvoir de hachage. C'est grâce au fait que les mineurs modifient les numéros de bits de version des blocs qu'ils exploitent. Ainsi, au moment où un certain nombre de blocs minés est atteint avec le changement des numéros de bits de version, les nœuds complets peuvent appliquer les nouvelles règles de consensus.
Un PLUS F est un des modéls soft fork qui repose sur la signalisation des mineurs via la puissance de hachage pour le déclencher.
Implémentation d'un MASF en Bitcoin
La Proposition d'amélioration Bitcoin (BIP) BIP 34, pour la mise à jour et l'amélioration des transactions et des blocs versionnés du réseau, a fourni un MASF dans le protocole. Où les mineurs devraient indiquer leur position d'accepter ou non les changements proposés dans le consensus. Pour cela, le changement que les mineurs ont dû faire était de mettre un nombre supérieur à 1 dans le numéro de version du bloc; en plus de demander que le numéro de la hauteur du bloc soit reflété dans l'entrée du transaction coinbase de chacun des blocs minés.
Donc, pour activer ce mécanisme, les mineurs devaient pointer vers le numéro de version du bloc. Être «1» pour les anciennes règles, et le changement de «1» à «2» pour indiquer l'acceptation et la transition vers les nouvelles règles.
Par conséquent, lors de la mise en œuvre de ce mécanisme, les mineurs pouvaient choisir d'accepter les modifications ou non; autrement dit, choisissez de créer une branche ou de la rejeter. Ainsi, dans les 1000 derniers blocs générés par les mineurs du réseau, 75% (représentant un total de 750 blocs) doivent contenir la signalisation de la version «1» à «2» pour indiquer que les changements seraient appliqués. De plus, ces mêmes 750 blocs devaient contenir la hauteur de bloc indiquée dans l'entrée de la transaction coinbase de chaque bloc.
A ce stade, les mineurs qui génèrent des blocs avec la version "1", émettent des blocs qui sont acceptés par le réseau. Ceci étant donné que tous les paramètres du BIP 34 n'étaient pas satisfaits, les blocs de la version 1 étaient donc toujours valides. Cependant, après avoir atteint 95% (soit un total de 950 blocs) des 1000 derniers blocs générés, les nouveaux blocs produits par les mineurs marqués de la version "1" sont considérés comme invalides et sont rejetés. Puisque désormais, les seuls blocs valides étaient ceux marqués avec la version "2" et qui avaient la hauteur de bloc dans l'entrée de la transaction coinbase.
Cette transition en deux parties a permis aux mineurs de mettre à jour leurs systèmes pour accepter les modifications proposées, de manière continue et systématique. Sans exiger de tous les mineurs qu'ils mettent en œuvre le changement instantanément et en même temps.
Autres implémentations de MASF
Après la mise en œuvre réussie du BIP 34, ce mécanisme a été utilisé de la même manière pour l'activation du BIP 66 (restriction des signatures DER strictes) et BIP 65 (OP_CHECHECKLOCKTIMEVERIFY). Lorsque la même structure de signalisation a été mise en œuvre, uniquement pour BIP 66, les mineurs ont dû signaler leur acceptation du fork en changeant la version "2" en version "3" dans les 1000 derniers blocs générés. Tous les blocs de la version "2" restent invalides lorsque 95% des blocs minés accepteront la version "3".
De même, pour l'activation de BIP 65, les mineurs ont dû faire une transition de la version «3» à la version «4», de la même manière, dans les 1000 derniers blocs générés dans le réseau. Invalidation des blocs de la version «3» lorsque 95% de ces 1000 4 blocs extraits avaient effectué le changement vers la version «XNUMX».
Mais ce mécanisme pour augmenter les versions 1 de 1 à chaque activation est devenu clairement limité. Principalement parce qu'il n'était possible d'augmenter que les versions 1 à la fois, et parce qu'il se limitait également à devoir activer la fourche souple précédente pour pouvoir activer la suivante.
Par conséquent, par la suite, de nouvelles modifications proposées ont été mises en œuvre dans le BIP 9, où le mécanisme de signalisation par les mineurs a changé. À ce stade, le numéro de version du bloc n'a pas marqué la signalisation. Au lieu de cela, il serait basé sur l'interprétation du champ de version comme un vecteur de bits. C'est-à-dire que l'activation du soft fork se ferait au moyen de différents bits dans le champ de version. De cette façon, la procédure d'augmentation du numéro de version a été laissée pour compte.
Cela a permis un grand avantage par rapport à la version précédente, car cela permettait d'ajouter et d'activer un plus grand nombre de fourchette souple simultanément, au lieu d'un seul à la fois.
Que savez-vous, cryptonuta?
Les fourches souples du type MASF peuvent-elles conduire à une fourche dure de la chaîne?VRAI!
L'application incorrecte d'un soft fork de type MASF peut effectivement provoquer la division de la blockchain en deux (hard fork), où les parties de la chaîne continuent de fonctionner avec des règles de consensus différentes. En effet, les mineurs et les nœuds peuvent utiliser différentes versions du logiciel et suivre différentes règles de consensus au sein du réseau, conduisant à cet événement étrange.
Implications de la mise en œuvre du MASF
Les Fourches souples activées par les mineurs (MASF) Ils permettent d'activer les nouvelles règles de consensus dans le protocole une fois que la majorité des nœuds sont mis à jour et acceptés.
Cependant, comme les mineurs utilisent uniquement leur pouvoir de hachage pour effectuer ce processus, cela peut être gênant. Ceci parce que cela implique que la puissance de calcul ou le taux de hachage indique que le fork est en cours d'exécution. Cependant, ils fonctionnent en fait sur les anciennes versions sans la fourche souple. Quelque chose de semblable s'est produit avec le BIP 66. À cette époque, de nombreux mineurs ont souligné les règles mais ne les ont pas appliquées. Cela a conduit les mineurs à créer une nouvelle chaîne (hard fork). Bien que cela soit rejeté par les mineurs qui ont appliqué le BIP 66. Ce qui signifiait que ces mineurs ont perdu toutes les récompenses et la puissance de calcul investie.
Auteur
