Bitcoin est un système de paiement distribué. Par nature, aucune personne ni aucune entité ne le dirige. Pourtant, son protocole est parfois modifié pour introduire de nouvelles fonctionnalités. Ces modifications sont généralement effectuées par le biais d'un mécanisme connu sous le nom de « soft fork ».
Pour implémenter ces soft forks de manière optimale tout en préservant l'intégrité du consensus actuel, des méthodes d'activation spécifiques sont utilisées. Ces mécanismes, bien que parfois méconnus, jouent un rôle crucial dans la compréhension des dynamiques liées aux modifications du protocole Bitcoin. Dans cet article, nous explorons les différentes méthodes d'activation de soft forks utilisées sur Bitcoin.
Quelle est la différence entre un soft fork et un hard fork ?
Le protocole Bitcoin est une chose de nature intangible. Il représente simplement un groupe de règles tacites, qui permettent aux différents nœuds de se synchroniser et de former un réseau. Tous ces nœuds implémentent les règles du protocole à travers un logiciel, le plus utilisé étant Bitcoin Core.
Lorsqu’une modification intervient sur ces règles du protocole, on appelle cet évènement un « fork ». Chaque nœud est ensuite libre de choisir s’il souhaite implémenter ce fork, ou s’il le refuse. C’est ainsi que le consensus est recherché pour chaque modification de Bitcoin, sans avoir besoin de faire appel à une autorité centrale.
Il existe principalement deux types de forks : les hard forks et les soft forks. La différence entre les deux se fait au niveau de la rétrocompatibilité de la mise à jour.
Le hard fork modifie le protocole en supprimant des règles ou en rendant moins restrictives celles existantes, ce qui le rend non rétrocompatible avec les anciens nœuds. Il provoque alors une séparation de la blockchain en deux chaînes distinctes : celle avec les nœuds à jour et celle avec les anciens nœuds.
Le soft fork, lui, modifie le protocole en ajoutant des règles ou en rendant plus restrictives celles déjà existantes. De cette manière, le nouveau protocole reste rétrocompatible avec l’ancien et aucune séparation de chaîne n’est censée se produire. Sur Bitcoin, sauf cas exceptionnel, on préfère employer des soft forks pour modifier les règles du protocole.
La difficulté réside dans le fait que, même avec l'utilisation d'un soft fork, il peut parfois y avoir une séparation de la blockchain en deux branches. Ce scénario se produit lorsque les mineurs n'ayant pas effectué la mise à jour représentent plus de 50 % de la puissance de calcul du réseau. Dans ce cas, l’embranchement en deux chaînes distinctes persiste aussi longtemps que la chaîne n'ayant pas intégré le soft fork dispose de plus de travail accumulé que celle l'ayant adopté.
Afin de préserver l’unité de Bitcoin, on souhaite à tout prix éviter de tels embranchements. Pour ce faire, on va demander aux mineurs de se prononcer en amont sur leur acceptation d’un soft fork. Si une large majorité signale leur accord pour le soutenir, les risques d’embranchement lors de l’activation du soft fork sont considérablement réduits. Ce processus de consultation et de consensus préalable, c’est ce qu'on appelle une « méthode d'activation ».
Quelle est la différence entre un UASF et un MASF ?
On différencie alors deux catégories de soft forks. Lorsque son implémentation provient directement des utilisateurs, on appelle cela un « UASF » (User-Activated Soft Fork). Cette méthode se produit lorsque les nœuds du réseau choisissent d'appliquer un soft fork en modifiant leurs logiciels, sans attendre l'approbation des mineurs. Employée généralement en situation d'urgence, notamment lorsque la majorité des mineurs s'oppose à l'adoption d'un soft fork, l'UASF est en réalité un instrument de dissuasion permettant aux utilisateurs de contrer un potentiel abus de pouvoir de la part des mineurs. Cependant, l'UASF n'est pas sans risques : il peut conduire à un embranchement de la blockchain, plaçant ainsi les utilisateurs qui l'adoptent sur une chaîne potentiellement sans valeur économique et moins sécurisée.
Dans un processus plus consensuel, on préfère utiliser une activation de soft fork par les mineurs. On parle alors d’un « MASF » (Miner-Activated Soft Fork). Dans ce cas, on laisse les mineurs donner leur approbation pour la modification du protocole. Lorsqu'une large majorité d’entre eux signalent leur accord pour le déploiement du soft fork, la mise à jour est alors validée puis activée un peu plus tard. Cette méthode permet d'éviter l’embranchement de la blockchain et de maintenir l'unité du réseau.
Vous l’aurez compris, puisqu’il n’y a pas de planification centrale sur Bitcoin, chaque mise à jour peut rapidement devenir chaotique. Les développeurs ont ainsi proposé diverses méthodes d’activation afin d’exécuter un soft fork en réduisant le risque de casser le consensus de Bitcoin.
Les méthodes d’activations informelles
À l'époque de Satoshi Nakamoto, il n'existait pas de procédure formelle pour l'activation des soft forks. C'est Satoshi lui-même qui apportait les modifications, lesquelles étaient généralement adoptées sans grande opposition par une communauté encore restreinte. Parfois, il ne les annonçait même pas en amont, comme lorsqu'il a unilatéralement imposé en 2010 une limite de 1 Mo à la taille des blocs.
Parmi les premières méthodes employées, on retrouve également le « Flag Day ». Elle consistait à fixer et à imposer une date précise pour activer le soft fork. Bien que simple, cette méthode est très rigide et ne permet pas de considérer d'éventuels désaccords au sein de la communauté.
Après le départ de Satoshi début 2011, des procédures d'activation plus formalisées commencent à émerger. L’activation du BIP16, qui introduit le P2SH (Pay-to-Script-Hash), était au centre d’un des premiers grands débats au sein de la communauté. C'est lors de cette période tendue que les premières méthodes d'activation considérant l'avis des mineurs furent utilisées.
Après ces débats sur P2SH, Gavin Andresen propose le BIP34, qui introduit un cadre initial pour les méthodes d'activation. Cette approche permettait de tenir compte de l’avis des mineurs et d'exécuter le soft fork une fois un certain seuil d'approbation atteint.
Par la suite, d'autres soft forks ont utilisé des méthodes similaires, avec des fenêtres d'activation s'étendant sur plusieurs semaines. Cependant, il n'existait toujours pas de méthode standardisée pour activer une modification du protocole. Les activations se faisaient en s'alignant plus ou moins sur les recommandations du BIP34, mais ce dernier ne prenait pas en compte la signalisation de plusieurs soft forks en simultané.
Activer un soft fork avec le BIP9
Le BIP9, conçu en 2015 par Pieter Wuille, Peter Todd, Greg Maxwell et Rusty Russell, établit un cadre standard pour l'activation des soft forks, en améliorant le concept initial du BIP34. Son fonctionnement est très simple. Lorsqu’un soft fork est décidé, la communauté le soumet à la signalisation des mineurs. Pour ce faire, une date de début et une durée maximale pour la signalisation sont déterminées. Pendant cette période, les mineurs peuvent utiliser un bit spécifique dans le champ de version des blocs pour indiquer leur soutien au soft fork.
Dès que 95 % des blocs signalent leur approbation sur une période fixe de 2016 blocs, le soft fork est alors verrouillé. Cette période coïncide avec chaque ajustement de la difficulté de la preuve de travail. Après ce verrouillage, une courte période est accordée aux mineurs pour s'aligner sur la mise à jour, avant l'exécution effective du soft fork. Si le seuil de 95 % d'approbation n'est pas atteint durant le délai imparti, le soft fork est abandonné.
Par rapport au BIP34, le BIP9 offre la possibilité de signaler plusieurs soft forks simultanément. Toutefois, il comporte lui aussi des inconvénients, notamment le fait qu'il repose entièrement sur un MASF, accordant ainsi un pouvoir considérable aux mineurs. En effet, si le seuil de 95 % de signalisation n'est pas atteint durant la fenêtre de vote, la proposition de modification est simplement abandonnée.
Le BIP9 a notamment été utilisé pour l'activation de SegWit en 2017. Comme vous le savez probablement, les choses ne se sont pas déroulées comme prévu. Pendant des mois, une majorité de mineurs a refusé de signaler leur accord pour SegWit, malgré le consensus des utilisateurs.
Ainsi, le BIP9 introduit une certaine ambiguïté dans la gouvernance de Bitcoin, laissant penser aux mineurs qu'ils contrôlent l'activation des soft forks. En réalité, leur rôle se limite à signaler leur préparation à adopter le nouveau code, afin d'éviter un embranchement de la blockchain. Malgré la complexité du sujet, ce sont bien les utilisateurs qui exercent un contrôle définitif sur le protocole, via leurs nœuds complets.
C’est pour cette raison que le développeur Shaolin Fry a proposé le BIP148 en mars 2017, qui permettait aux utilisateurs de faire un UASF. Le but était d’imposer SegWit aux mineurs, sans leur consentement. Cette initiative largement soutenue par la communauté a exercé une pression suffisante sur les mineurs, qui, par peur de perdre leurs revenus, ont finalement approuvé SegWit par un processus de signalisation plus classique.
Le processus d’activation de SegWit a ainsi tourné au fiasco et aurait pu être un désastre pour Bitcoin. C’est pour cette raison qu’en 2017, Shaolin Fry et Luck Dashjr ont proposé le BIP8, une nouvelle méthode d’activation qui reprend l’idée du BIP9 tout en y ajoutant un mécanisme automatique d’UASF à l'issue de la période de vote.
Il spécifie un nouveau paramètre nommé « LOT » (lock in on time out), qui peut prendre la valeur de « vrai » ou de « faux ». Si cette variable est réglée sur « faux », le BIP8 fonctionne de manière semblable au BIP9. Une fenêtre d'approbation pour les mineurs est spécifiée et, une fois le seuil atteint, le soft fork est verrouillé. En revanche, si le paramètre LOT est réglé sur « vrai », le BIP8 prévoit qu'en cas de non atteinte du seuil requis à l'expiration de la période de vote, un UASF sera automatiquement déclenché par les utilisateurs. Ce mécanisme vise à exercer une pression sur les mineurs pour forcer l'activation du soft fork en cas de blocage dans le processus d'approbation.
Le BIP8 avec LOT activé est donc une méthode beaucoup plus agressive contre les mineurs. Elle leur laisse seulement deux choix :
Être coopératifs, et ainsi faciliter le processus d'activation ;
Être non coopératifs, auquel cas les utilisateurs font un UASF pour imposer le soft fork.
Le BIP8 est également venu rectifier quelques défauts du BIP9. Au lieu d’utiliser les horodatages pour spécifier la période de vote, il la paramètre sur la hauteur des blocs. De cette manière, le BIP8 élimine la possibilité que les mineurs fassent brutalement chuter le taux de hachage sur le réseau pour fausser le processus. De plus, il ajoute la possibilité de déterminer librement le seuil minimum de vote et introduit un paramètre spécifiant une hauteur de bloc minimale, en deçà de laquelle le soft fork ne peut pas être activé. Ce paramètre offre aux mineurs le temps nécessaire pour se préparer à la modification du code, tout en leur permettant de signaler leur accord à l'avance.
Activer un soft fork en Speedy Trial
Le processus « Speedy Trial », proposé par David A. Harding début 2021 sur une idée de Russell O'Connor, est une nouvelle méthode d'activation conçue initialement pour le soft fork Taproot. Elle repose sur l'utilisation du BIP8 avec le paramètre LOT réglé sur « faux », mais avec une réduction significative de la fenêtre d'activation à seulement trois mois. De cette manière, l’approbation des mineurs peut être vérifiée très rapidement. Si le seuil requis est atteint durant une des périodes, le soft fork est activé plusieurs mois plus tard, laissant ainsi suffisamment de temps aux mineurs pour mettre à jour leurs logiciels. Bien que cette méthode n'ait pas encore été formalisée dans un BIP spécifique, elle a déjà été utilisée pour activer Taproot en novembre 2021.
Malgré son efficacité pour Taproot, qui disposait d'un large consensus dans la communauté, la méthode du Speedy Trial n'est pas nécessairement la plus adaptée pour toutes les mises à jour de Bitcoin. Certains développeurs expriment des réserves quant à son utilisation future, craignant qu'elle ne favorise une succession trop rapide de soft forks et, par conséquent, qu'elle ne compromette la stabilité du protocole Bitcoin.
Les méthodes d'activation de soft forks sur Bitcoin évoluent au fil des nouvelles mises à jour. C’est un schéma d’essai-erreur qui est assez semblable à chaque fois : on définit un standard de méthode d’activation ; on l’utilise pour le prochain grand soft fork ; cela ne se passe pas comme prévu ; donc on définit un autre standard en considérant nos erreurs passées.
À ce jour, il existe principalement trois méthodes d’activation :
Le BIP9, qui permet de demander aux mineurs leur approbation avant d’activer un soft fork ;
Le BIP8, qui est essentiellement comme le BIP9, mais qui ajoute la possibilité d’un UASF automatique si les mineurs ne sont pas coopératifs ;
Et le Speedy Trial, qui est comme le BIP8, mais avec une période de vote très réduite.
.png)
.png)
.png)
