Le sophisme du soft fork

Pour justifier leur légitimité à conserver le nom de Bitcoin, on entend parfois certains partisans de Bitcoin-BTC dire que leur protocole serait LE seul et unique Bitcoin car il serait celui qui n'a pas fondamentalement changé, par opposition à Bitcoin Cash qui a augmenté la taille limite des blocs en 2017. Pour cela, ils affirment que seuls les soft forks sont acceptables, car « rétrocompatibles » et « optionnels » pour les nœuds du réseau, contrairement aux hard forks. En ce sens, ils sous-entendent que cette méthode de mise à jour serait bénigne et qu'elle ne pourrait pas fragiliser l'intégrité du protocole. Le site Bitcoin.fr parle même du soft fork comme une « mise à jour mineure et optionnelle ».

BashCo à propos de SegWit et de Bitcoin Cash

BashCo : « La différence c'est que SegWit était un soft fork rétrocompatible alors que [Bitcoin Cash] était un fork incompatible, ce qui consiste juste, en réalité, à cloner la chaîne de blocs de Bitcoin pour créer un nouvel altcoin. »

Les soft forks sont en effet rétrocompatibles, dans le sens où les nœuds utilisant une ancienne version du logiciel continuent de voir les blocs produits par la nouvelle version comme valides. SegWit est l'archétype de la mise à niveau implémentée comme un soft fork : les nœuds et portefeuilles ne supportant pas SegWit peuvent toujours interagir avec le réseau. C'est d'ailleurs pour cela que Bitcoin-BTC a pu conserver son effet de réseau, alors même que SegWit a été activée en août 2017.

Cependant, cette vision du soft fork est selon moi très biaisée. Les soft forks ne sont pas des procédés aussi doux qu'on le croit et c'est ce que je vais tenter de montrer ici.

Qu'est-ce qu'un soft fork ?

Avant d'expliquer ce qu'est un soft fork, il faut décrire ce qu'est un fork. Un fork (ou embranchement en français) est une séparation de la chaîne de blocs en deux chaînes distinctes. Cela peut se produire au sein du processus de consensus lui-même, notamment lorsque deux mineurs trouvent un bloc dans un intervalle de temps réduit. Dans ce cas, les deux blocs trouvés sont tout à fait valides et rien ne peut déterminer lequel est le bon. Les nœuds sélectionnent la première solution qu’ils recoivent et cela entraîne une séparation du réseau en deux parties : l’une qui considère que le premier bloc est valide et le second invalide, l’autre qui considère que le second bloc est valide et le premier invalide.

Cela crée deux chaînes de blocs distinctes qui sont en concurrence. La situation est résolue lorsque l’un mineur trouve un nouveau bloc : c’est alors la plus longue chaîne, c'est-à-dire la chaîne possédant le plus de travail accumulé, qui est sélectionnée comme valide par l'entièreté du réseau.

Un fork peut également avoir lieu de manière irréversible : c'est ce qu'on appelle un hard fork. Un hard fork est un embranchement de la chaîne produit par une modification accidentelle ou délibérée des règles de consensus : deux chaînes distinctes sont créées et ne reconvergent pas vers une chaîne unique.

Par extension, on parle généralement de hard fork pour désigner la méthode de mise à jour qui rend les nouvelles règles incompatibles avec les anciennes. Un hard fork, en tant que méthode, est donc susceptible de provoquer un hard fork de la chaîne. Cette méthode est souvent décriée car ele requière que tous les nœuds du réseau se synchronisent pour effectuer le changement de règles.

Un hard fork peut être extensif, c'est-à-dire élargir les règles de consensus. Les anciens nœuds pourront ainsi produire des blocs valides sur la nouvelle chaîne, mais pas l'inverse. L'exemple typique de ce genre de hard fork est celui d'une augmentation de la taille limite des blocs (de 1 à 2 Mo par exemple). Un hard fork peut aussi être bilatéral, c'est-à-dire provoquer une incompatiblité des deux côtés. Un changement de l'algorithme de signature serait, par exemple, bilatéral. C'est cette dernière option qui est préférée par les hard forks contentieux en général : le hard fork de Bitcoin Cash était en effet bilatéral.

Cela nous amène au soft fork, qui par opposition au hard fork extensif, consiste à restreindre les règles de consensus : on ne peut que rajouter des règles et non en enlever. Cette restriction stricte des règles garantit le caractère rétrocompatible de la mise à jour. L'exemple typique de soft fork est celui d'une diminution de la taille limite des blocs : de 1 Mo à 500 ko par exemple.

Le terme de soft fork est ambigu car il ne s'agit pas d'un fork. Ce changement des règles de consensus ne provoque pas de duplication permanente de la chaîne si il est suivi par plus de 50 % de la puissance de calcul du réseau.

Un soft fork n'est pas si optionnel que cela

Le hard fork est souvent vu comme une mauvaise chose, à cause de son caractère brutal et inconditionnel. Les nœuds du réseau sont en effet obligés de mettre à jour leur logiciel s'ils veulent continuer à interagir avec le protocole. Mais le soft fork n'est pas pour autant exempt de tout défaut à ce niveau-là, comme on va le voir.

On parle beaucoup du caractère facultatif et rétrocompatible des soft forks, mais on évoque rarement le fait qu'il ne s'applique évidemment pas pour les mineurs qui ont tout à perdre dans l'opération.

S'il est suivi par plus de 50 % des mineurs (en terme de taux de hachage), alors le soft fork s'applique pour tous. Pour reprendre notre exemple de la diminution de la taille limite des blocs, la chaîne contenant les « petits blocs » (≤ 500 ko) sera toujours la plus longue chaîne en terme de preuve de travail accumulée. Les mineurs des « gros blocs » (≤ 1 Mo) seront contraints de suivre la chaîne majoritaire des petits blocs et verront leurs blocs rejetés (orphaned). Le soft fork peut donc être être introduit de manière forcée par une majorité des mineurs si le reste du réseau ne réagit pas en provoquant volontairement un hard fork.

S'il est suivi par moins de 50 % des mineurs, alors le soft fork est susceptible de provoquer un hard fork de la chaîne. Dans le cas de la diminution de la taille limite des blocs, les mineurs de la chaîne des « petits blocs » (≤ 500 ko) rejeteront la chaîne des gros blocs de la chaîne majoritaire, ce qui provoquera une séparation permanente du réseau.

Ainsi, le soft fork présente des défauts majeurs. Dans le premier cas, il est même plus pernicieux qu'un hard fork, ce dernier ayant au moins le mérite d'être clair et d'obliger les utilisateurs à choisir une chaîne.

Modifier la politique monétaire de Bitcoin par un soft fork

L'autre aspect sur lequel insistent certains défenseurs des soft forks est qu'ils ne peuvent constituer que des changements mineurs du protocole en tant que restrictions des règles de consensus. C'est complètement faux : un soft fork peut être un changement majeur du protocole.

Prenons l'exemple de la règle des 21 millions, qui dérive de la politique d'émission monétaire du protocole et qui garantit qu'il n'y aura jamais plus de 21 millions de bitcoins en circulation. Cette règle est sans doute l'un des aspects fondamentaux de Bitcoin, qui se veut déflationniste.

Premièrement, cette règle n'est pas aussi immuable qu'on peut le croire : il est toujours possible de modifier le protocole. Sa validité dans le temps repose sur les incitations économiques des acteurs de l'écosystème, en particulier celles des commerçants et des utilisateurs qui utilisent le bitcoin comme réserve de valeur.

Secondement, on pourrait croire qu'il faille remédier à un hard fork pour augmenter la limite de rémunération des mineurs, mais non. Il est en effet tout à fait possible de contourner la limite sur l'émission monétaire de Bitcoin par un soft fork !

Ce changement consiste à redéfinir le jeton utilisé au sein du protocole. Voyons comment cela peut être fait. Conformément à l'article de Peter Todd sur le sujet, appelons Bitcoin 1.0 le protocole respectant la politique déflationniste initiale, et Bitcoin 2.0 celui voulant instaurer une politique inflationniste. Les nouvelles règles seront :

Chaque bloc de Bitcoin 1.0 ne devra contenir qu'une seule transaction : la transaction de récompense (coinbase).
Cette transaction de récompense devra contenir l'empreinte d'un bloc de Bitcoin 2.0.
Le jeton bitcoin 2.0 suivra les mêmes règles que le bitcoin 1.0 au détail près qu'il sera soumis à une émission monétaire de 5 % par an.

Il s'agit bien là d'un soft fork puisque les règles sont simplement restreintes. Les nœuds utilisant une version de Bitcoin antérieure à ce soft fork verront simplement des blocs vides s'enchaîner jusqu'à la fin des temps. Les nœuds suivant les nouvelles règles seront eux en mesure de suivre l'activité économique réelle de la chaîne.

Cet exemple est extrême, mais il devrait titiller Saifedean Ammous, grand défenseur de la politique déflationniste de Bitcoin, qui n'a pas bronché lors de l'activation du soft fork SegWit, alors qu'il ne soutiendrait jamais, ô grand jamais, un hard fork pour augmenter la taille limite des blocs.

L'abominable SegWit

SegWit (abréviation de Segregated Witness) est une mise à jour qui modifie en profondeur la structure des transactions et des blocs en déplaçant les données de signature (le témoin ou witness) dans une base de données séparée (segregated). Aussi étonnant que ça puisse paraître, SegWit a pu être implémentée sous la forme d'un soft fork et cela a pu être réalisé en redéfinissant le concept de bloc.

L'objectif premier était de corriger la malléabilité, mais SegWit a permis par ce biais d'augmenter la taille réelle des blocs, c'est-à-dire la taille des données conservées par les nœuds. Les nœuds suivant les règles pré-SegWit voient toujours des blocs dont la taille est inférieure à 1 Mo. Cependant, les nouvelles règles font que les nouveaux blocs peuvent dépasser cette limite de 1 Mo et ceci jusqu'à 4 Mo en théorie¹.

SegWit est donc une mise à niveau importante. C'est pourquoi certains parlent de « hard fork déguisé » : on élargit les règles de consensus en les restreignant. Si SegWit avait été acceptée par tous, ce n'aurait pas été un problème. Cependant, SegWit était une mesure contestée, notamment par ceux qui défendaient un hard fork pour augmenter la taille limite des blocs. Ce n'est d'ailleurs pas un hasard si Bitcoin Cash a été créé avant son activation en août 2017.

Car il faut le dire : en tant que soft fork, SegWit apporte son lot de complications. Il s'agit en effet un monstre de complexité, qui augmente drastiquement la dette technique de Bitcoin. Cette complexité rend la tâche plus difficile pour les développeurs, car SegWit intervient à de nombreux niveaux dans le code de base. Mais surtout, elle se fait ressentir pour les utilisateurs. Pas moins de 4 nouveaux types d'adresse ont fait leur apparition alors qu'il n'en existait que deux avant. Pire : il s'avère que certains de ces types sont incompatibles entre eux ; il est impossible d'envoyer des fonds à une adresse bech32 (commençant par un bc1) à partir d'une adresse traditionnelle (commençant par un 1). [correction déc. 2021]

De plus, cette complexité ne risque pas de diminuer car les principales innovations de Bitcoin auront lieu grâce au versionnage des scripts inclus dans SegWit. Les signatures de Schnorr seront par exemple implémentées avec la version 1 de SegWit (seule la version 0 est utilisée pour le moment).

Conclusion

Les soft forks ne sont donc pas si doux qu'on le croit. Si certaines mises à jour gagnent à être implémentées comme des soft forks, ce n'est pas le cas de toutes. La rétrocompatibilité, principal avantage d'un soft fork, n'est pas toujours parfaite. D'une part, comme on l'a vu dans la première partie, elle ne s'applique pas pour les mineurs. D'autre part, même si les nœuds peuvent encore interagir avec le réseau, il est possible que cette interaction perde en utilité, que cette perte soit partielle (les nœuds pré-SegWit ne voient pas les signatures liées aux nouvelles transactions) ou totale (avec un Bitcoin 2.0 qui introduit de l'inflation par exemple). Cela force donc les intéressés à mettre à jour leur logiciel.

Notes

1. ↑ La nouvelle limite est calculée en unités de poids (weight units ou WU). Le poids des transactions et des blocs est défini par :

poids = 4 × taille de base + taille du témoin

Actuellement, le poids des blocs est limité à 4 MWU, ce qui autorise la taille réelle des blocs à aller jusqu'à 4 Mo. Ceci n'est pas réaliste car il faudrait pour cela restreindre le plus possible la taille de base (donc n'avoir qu'une transaction dans le bloc) et inclure le reste des données dans le témoin. La limite pratique doit se trouver autour des 2 Mo.