Soft fork activé par les utilisateurs

L'idée inverse l'ordre habituel des opérations. Au lieu d'attendre que la puissance de calcul signale qu'elle est prête, les nœuds qui reçoivent des paiements annoncent une date après laquelle ils refuseront tout bloc non conforme. Le BIP-148 a fixé cette date au 1er août 2017, et la menace crédible qu'il représentait est largement créditée d'avoir mis fin à un blocage de signalisation qui durait depuis novembre 2016.

Comment cela fonctionne

C'est la validation, et non le minage, qui fait appliquer une règle en dernier ressort, et un soft fork activé par les utilisateurs repose sur ce fait.

Un nœud décide par lui-même quels blocs sont valides. Si une part suffisante de l'économie, les plateformes d'échange, les processeurs de paiement et les dépositaires avec lesquels les gens règlent réellement leurs transactions, exécute un logiciel qui rejette les blocs non conformes, alors un mineur qui produit ces blocs est payé en bitcoins que personne n'acceptera. La récompense de bloc ne vaut quelque chose que si la chaîne sur laquelle elle se trouve est celle que les acheteurs reconnaissent, si bien que l'incitation pousse à la conformité sans qu'aucun vote n'ait lieu.

Le mécanisme repose sur une date plutôt que sur un seuil. Le BIP-148 exigeait qu'à partir du 1er août 2017 chaque bloc signale sa préparation à SegWit, et demandait aux nœuds de traiter comme orphelins les blocs qui ne le faisaient pas. Il s'agit d'un durcissement, donc une chaîne conforme reste valide pour les nœuds qui n'ont jamais été mis à jour. Ce que ce mécanisme ne supprime pas, c'est le risque de scission : si la majorité de la puissance de calcul continue de miner des blocs non conformes, le camp qui applique la règle dispose de moins de travail accumulé, et les deux chaînes coexistent jusqu'à ce qu'un camp cède.

Le BIP-8 a ensuite transformé cette approche en un ensemble de paramètres généraux. Il compte les signaux comme le fait le BIP-9, mais ajoute lockinontimeout, généralement écrit LOT. Avec LOT à false, le déploiement expire simplement si les mineurs n'atteignent jamais le seuil. Avec LOT à true, il se verrouille à la hauteur du délai quoi qu'il arrive, ce qui est un soft fork activé par les utilisateurs exprimé sous forme de paramètre de configuration.

Où le voit-on

La séquence de 2017 est le seul exemple achevé sur bitcoin, et il vaut la peine de la connaître dans l'ordre. Le BIP-148 a été publié en mars 2017 par un développeur utilisant le nom Shaolin Fry, puis repris par des opérateurs de nœuds au cours du printemps. Face à une échéance en août, les mineurs ont adopté le BIP-91 en juillet pour rendre la signalisation de SegWit obligatoire entre eux. SegWit s'est alors verrouillé au bloc 479 808 le 8 août 2017 et est devenu applicable au bloc 481 824 le 24 août 2017. La date fixée est arrivée sans scission durable, car le résultat qu'elle exigeait était déjà acquis.

L'approche est réapparue avant Taproot. Tout au long de la fin 2020 et du début 2021, le débat a porté entièrement sur la question de savoir s'il fallait livrer le BIP-8 avec LOT à true ou à false, un client alternatif avec LOT à true a été publié, et le compromis a été Speedy Trial, qui fixait une courte fenêtre sans activation forcée. Les mineurs ont atteint le seuil en juin 2021, si bien que la question n'a jamais été mise à l'épreuve.

Si vous détenez du bitcoin, la conclusion pertinente est que c'est l'exécution de votre propre nœud qui donne à tout cela du poids. Un soft fork activé par les utilisateurs compte les utilisateurs qui valident, et une personne dont le solde réside entièrement sur une plateforme d'échange est représentée par le logiciel de cette plateforme, pas par le sien.

Soft fork activé par les utilisateurs vs hard fork

Un soft fork activé par les utilisateurs resserre les règles ; un hard fork les assouplit, et la confusion de 2017 venait du fait que les deux comportaient un risque de scission. Avec le BIP-148, un ancien portefeuille continuait de fonctionner et la chaîne résultante restait valide pour toutes les versions précédentes du logiciel, ce qu'un hard fork ne peut précisément pas promettre. Le risque de scission était temporaire et dépendait du comportement des mineurs, alors que la scission d'un hard fork est prévue dès le premier bloc incompatible.