)
)
Pour que Bitcoin puisse fonctionner, il faut que tous les utilisateurs s'accordent sur un historique des transactions (la blockchain) et sur un ensemble de règles fondamentales définissant ce qui est accepté sur cette blockchain ou non. Lorsque ce consensus ne peut être atteint, la communauté d’utilisateurs peut se diviser en deux réseaux distincts, chacun avec ses propres règles. C’est précisément ce qu’il s’est passé en 2017 lors du hard fork ayant donné naissance à Bitcoin Cash (BCH).
Mais comment en est-on arrivé là ? Dans cet article, je vous propose de revivre cette période de conflits au sein de la communauté Bitcoin, connue sous le nom de « Blocksize War », afin de comprendre en quoi ce débat a durablement façonné l’idéologie des bitcoiners.
L’origine du conflit
La Blocksize War trouve ses origines dans un débat technique sur la capacité de Bitcoin à traiter un volume croissant de transactions. C’est ce que l’on appelle parfois la « scalabilité » ou le « passage à l’échelle ». Au fil de son adoption comme moyen de paiement, l’invention de Satoshi doit être capable de prendre en charge les transactions des nouveaux utilisateurs, tout en maintenant des frais raisonnables.
Parmi ces limitations techniques qui réduisent le flux de transactions, il y a évidemment la taille limite des blocs de la blockchain. Plus les blocs sont grands, plus il est possible d’y inclure un grand nombre de transactions à confirmer.
À son lancement en 2009, Bitcoin ne comportait pas de limite explicite sur cette taille. Cependant, en 2010, Satoshi Nakamoto a introduit une limite fixée à 1 mégaoctet (via la constante MAX_BLOC_SIZE). Cette modification avait pour but de prévenir les attaques de spam de transactions et de garantir une certaine décentralisation du réseau en évitant que des blocs trop volumineux ne monopolisent les ressources des opérateurs de nœuds.
La taille de 1 Mo était, à l’époque, largement suffisante pour supporter le faible nombre de transactions sur le réseau. Toutefois, à mesure que Bitcoin a gagné en popularité, la communauté a commencé à débattre de la nécessité d’augmenter cette limite pour permettre une meilleure gestion du volume transactionnel sans que les frais s'envolent. C’est ainsi qu’a émergé une première fracture au sein de la communauté Bitcoin. Certains, que l’on appellera plus tard les « big blockers », estimaient qu’une augmentation de la taille des blocs était une solution simple et directe pour résoudre les problèmes de congestion. À l’opposé, d’autres, que l’on désignera comme les « small blockers », soutenaient que cette approche risquait de centraliser le réseau en augmentant les exigences matérielles des nœuds.
En effet, puisque chaque nœud complet doit vérifier puis conserver en mémoire l’intégralité de la blockchain, des blocs plus volumineux nécessitent des disques de plus grande capacité, ce qui coûte plus cher et réduit les incitations à faire tourner son propre nœud. S'il y a moins de nœuds Bitcoin, la sécurité du système est moins bien distribuée, ce qui augmente les risques individuels de coercition en concentrant la sécurité sur un nombre réduit d’acteurs.
Ces discussions sur la taille des blocs sont même plus anciennes que la période 2015-2017. En réalité, dès 2010, des propositions avaient déjà été faites pour augmenter la limite, comme par exemple le patch proposé par Jeff Garzik.
Mais c’est véritablement à partir de 2015 que le débat va se transformer en conflit, avec une première offensive de la part des développeurs de Bitcoin XT, un client alternatif lancé par Mike Hearn et soutenu par Gavin Andresen (ancien mainteneur principal de Bitcoin suite au départ de Satoshi Nakamoto). Bitcoin XT était à l'origine une implémentation du protocole Bitcoin compatible avec Bitcoin Core. Cependant, en août 2015, la version 0.11A de Bitcoin XT a adopté le BIP101 : un hard fork qui augmente immédiatement la limite de la taille des blocs de 1 Mo à 8 Mo, avec en plus un mécanisme pour doubler cette limite tous les deux ans, jusqu'à atteindre un peu plus de 8 Go par bloc en 2036. De fait, les nœuds Bitcoin XT se sont donc séparés du reste du réseau Bitcoin. Ce tour de force est considéré par beaucoup comme le casus belli de la guerre de la taille des blocs.
){kind=logo}
Les small blockers contre les big blockers
Le conflit de la Blocksize War s'est structuré autour de deux camps opposés : les « big blockers » et les « small blockers », chacun défendant une approche différente pour résoudre le problème de la scalabilité de Bitcoin.
Les « big blockers » étaient en faveur d'une augmentation de la taille des blocs, afin de permettre à Bitcoin de traiter un plus grand nombre de transactions. Pour eux, une telle approche était nécessaire pour réduire les frais de transaction et améliorer l'expérience utilisateur à mesure que Bitcoin gagnait en popularité. Ils soutenaient également que cette solution était techniquement simple à mettre en œuvre via des hard forks. Les « big blockers » étaient notamment soutenus par des développeurs de la première heure, tels que Gavin Andresen, Jeff Garzik, Mike Hearn, et des acteurs influents comme Roger Ver et la majorité des entreprises de minage. Pour ces dernières, l’augmentation de la taille des blocs était synonyme d'une augmentation de leurs revenus. En effet, si l’on peut mettre plus de transactions dans chaque bloc, on peut également récolter plus de frais.
À l'opposé, les « small blockers », principalement représentés par les développeurs de Bitcoin Core comme Pieter Wuille, Wladimir van der Laan, Peter Todd, Gregory Maxwell, ou encore Luke Dashjr, étaient plus conservateurs dans leur approche. Ils soutenaient que l'augmentation de la taille des blocs poserait des risques de centralisation du réseau, car elle imposerait une charge plus lourde aux nœuds, ce qui limiterait la distribution des risques. Les « small blockers » souhaitaient également que Bitcoin puisse passer à l’échelle, mais ils préconisaient plutôt des solutions d'évolutivité qui déplaçaient des transactions en dehors de la blockchain principale, comme le Lightning Network par exemple. L’idée était de gérer un grand volume de transactions sans modifier le protocole de base pour préserver la décentralisation du réseau, et donc la distribution de sa sécurité. Les small blockers préfèrent également les changements conservateurs opérés via des soft forks plutôt que des hard forks.
➤ Quelle est la différence entre un hard fork et un soft fork ?
Le débat technique entre ces deux visions de la scalabilité a profondément divisé la communauté Bitcoin. Chaque camp a mobilisé des stratégies de propagande et d'influence pour essayer de faire passer ses idées.
Les propositions et les tentatives de forks
Les tentatives et les propositions de forks se sont multipliées entre 2015 et 2017. Comme nous l’avons vu, la première véritable tentative de fork durant la Blocksize War est celle du BIP101 sur Bitcoin XT. Cette proposition était soutenue par une large partie des mineurs, et par des sociétés alors influentes comme BitPay, Blockchain.info ou encore Circle. Finalement, Bitcoin XT ne parviendra pas à obtenir suffisamment de soutien de la part de la communauté, et Mike Hearn finira par annoncer son départ et la vente de ses bitcoins. Il exprimera sa déception dans un article de blog où il déclarera notamment que « Bitcoin a échoué ». Bitcoin XT a ainsi marqué le début des divergences profondes dans la communauté, et d'autres forks ont rapidement suivi.
Au début de décembre 2015, Pieter Wuille et Gregory Maxwell, des développeurs de Bitcoin Core, ont proposé un soft fork appelé « SegWit » (Segregated Witness). Cette proposition visait à séparer les données de signature des données de transaction dans la blockchain, afin de résoudre le problème de la malléabilité des transactions. Ce problème, lié à ECDSA, l'algorithme de signature numérique utilisé sur Bitcoin depuis 2009, permet de modifier légèrement une signature valide pour créer une autre signature valide pour une même transaction. Cette vulnérabilité empêchait l'implémentation du Lightning Network. L'intention de Maxwell et Wuille avec SegWit était donc de permettre un déploiement sécurisé du Lightning Network, et ainsi de résoudre les problèmes de scalabilité de Bitcoin. SegWit incluait également une augmentation légère et virtuelle de la taille des blocs, tout en restant compatible avec les anciens nœuds (soft fork). Cette proposition est rapidement devenue le fer de lance des small blockers.
){kind=logo}
Cependant, suite à l’échec de Bitcoin XT, Gavin Andresen et Jeff Garzik reviennent quelques semaines plus tard avec une nouvelle idée : Bitcoin Classic. Proposé début 2016, ce fork suggérait une approche plus modérée et consensuelle que Bitcoin XT, avec une augmentation de la taille des blocs à 2 Mo (via le BIP109). L’initiative était soutenue par de nombreuses entreprises du secteur comme Coinbase ainsi que par les mineurs.
){kind=logo}
À mesure que Bitcoin Classic gagnait en popularité et menaçait de scinder le réseau, une réunion d’urgence fut organisée le 20 février 2016 : la Hong-Kong Roundtable. Cet événement rassembla les mineurs (notamment Jihan Wu et Micree Zhan, les cofondateurs de Bitmain), certaines entreprises influentes et les développeurs de Bitcoin Core (notamment Luke Dashjr, Matt Corallo et Peter Todd). Après de longues heures de négociation, un accord fut trouvé. Les développeurs de Core s'engagent à implémenter un hard fork pour SegWit ainsi qu'à doubler la taille limite des blocs. De leur côté, mineurs et entreprises promettent de soutenir ce fork et d'utiliser exclusivement le client Bitcoin Core, dans le but de préserver l'unité du réseau Bitcoin.
Cet accord était censé mettre fin à la Blocksize War, mais il a finalement créé davantage de conflits. Chaque camp a interprété l'accord différemment et il ne sera finalement jamais mis en œuvre.
Certains événements externes sont également venus affaiblir cet accord, notamment le piratage de The DAO sur Ethereum, qui a conduit à un hard fork pour récupérer les fonds volés, entraînant ainsi la scission entre ETH (Ethereum) et ETC (Ethereum Classic). Ce hard fork s'est avéré être un désastre pour Ethereum, notamment à cause des attaques par rejeu qui ont perturbé l’ensemble de l’industrie (les transactions d’une blockchain pouvaient être rediffusées à l’identique sur l’autre blockchain). Ce fiasco a mis en lumière tous les risques qu’un hard fork pouvait faire peser sur Bitcoin, et a donc fourni un argument important aux small blockers, qui se sont retrouvés en position de force. En parallèle, d’autres événements ont terni la réputation de certains big blockers, ce qui est venu réduire leur crédibilité auprès de la communauté. Cet accord d'Hong-Kong a tout de même eu le mérite de freiner l'élan de Bitcoin Classic.
Les small blockers profitent de cette notoriété pour lancer le signalement de SegWit seul, en paramétrant que le soft fork soit activé si 95 % de la puissance de calcul l’approuve sur une période donnée. Cependant, durant les premières semaines, le signalement reste faible et les mineurs ne semblent pas vouloir coopérer. En parallèle, une nouvelle proposition de fork gagne en popularité avec Bitcoin Unlimited. Ce client alternatif, promu notamment par l’entrepreneur Roger Ver (surnommé « Bitcoin Jésus »), propose d’augmenter la taille des blocs de manière flexible via un hard fork. Contrairement à Bitcoin Classic, Bitcoin Unlimited ne fixe pas de limite supérieure à la taille des blocs, ce qui permet aux utilisateurs de définir leurs propres paramètres.
){kind=logo}
C’est sous la menace de ce nouveau fork que le BIP148 est publié en mars 2017 par un développeur anonyme se faisant appeler Shaolin Fry. L’objectif du BIP148 est de forcer l’activation de la mise à jour SegWit sur le protocole Bitcoin, face à la stagnation de la signalisation de ce soft fork par les mineurs via la méthode classique du BIP9. Pour y parvenir, il propose la mise en œuvre d’un UASF (User-Activated Soft Fork), afin d’activer SegWit de force par les nœuds le 15 novembre 2017, si jamais les mineurs n’avaient pas verrouillé SegWit d’ici au 1ᵉʳ août 2017. Si le BIP148 est suivi par les utilisateurs, les nœuds du réseau Bitcoin refuseront les blocs ne signalant pas le support à SegWit, ce qui exercerait ainsi une pression sur les mineurs pour qu’ils adoptent la mise à jour.
➤ Qu'est-ce qu'un BIP (Bitcoin Improvement Proposal) ?
Le dénouement de la Blocksize War
La communauté voit dans cette proposition d’UASF une occasion de faire enfin plier les big blockers et commence donc à la soutenir activement. Des vêtements arborant le sigle UASF apparaissent dans les conférences et la communication s’intensifie sur Twitter.
)
Face à la menace de l’UASF, les big blockers se voient contraints de revenir à la table des discussions malgré leur position de force suite à l’échec du signalement de SegWit. C’est ainsi que le 23 mai 2017, une nouvelle réunion privée est organisée à New York, en marge de la conférence Consensus 2017, rassemblant plus de 50 entreprises de l’écosystème Bitcoin. De cette rencontre naît la proposition SegWit2x, qui prévoit deux modifications majeures du protocole Bitcoin :
L’adoption de SegWit avec un seuil d’activation fixé à 80 % de signalisation ;
Un hard fork pour augmenter la taille maximale des blocs de 1 Mo à 2 Mo.
James Hilliard (ingénieur chez Bitmain) propose alors le BIP91 pour faciliter l'activation du soft fork SegWit, défini dans les BIP141, BIP143 et BIP147, via un MASF à 80 %. Cette méthode vise à rendre le BIP148 (UASF) obsolète et à éviter une scission potentielle de la blockchain le 1ᵉʳ août 2017. Le BIP91 est finalement activé le 23 juillet 2017 (au bloc 477 120), juste avant la date critique du 1ᵉʳ août fixée par le BIP148. Cela permet de forcer le signalement de SegWit par les mineurs, qui sera finalement verrouillé le 9 août au bloc 479 808, puis activé le 24 août au bloc 481 824.
L’UASF n’a donc jamais eu lieu, mais il a joué un rôle déterminant dans l’adoption de SegWit en contraignant les mineurs à verrouiller le soft fork via le BIP91. À plus long terme, le BIP148 a établi un précédent important, démontrant l’influence que les utilisateurs peuvent exercer via leurs nœuds complets sur les décisions de gouvernance du protocole Bitcoin, même si les grandes entreprises et les mineurs ne sont pas d’accord.
En parallèle de l’activation de SegWit, le 1ᵉʳ août 2017 au bloc 478 559, une partie de la communauté Bitcoin procède à un hard fork pour augmenter la taille des blocs à 8 Mo. Cette scission, nommée Bitcoin Cash (BCH), existe encore aujourd’hui en parallèle de Bitcoin, bien que sa valorisation soit très faible en comparaison.
){kind=logo}
Après l’activation de SegWit, la seconde partie de SegWit2x devait encore être mise en place au bloc 494 784, soit durant le mois de novembre 2017, via un hard fork destiné à doubler la taille des blocs. Cependant, les small blockers s’opposaient fermement à cette mise à jour, notamment parce qu’il s’agissait d’un hard fork sans tous les mécanismes de sécurité nécessaires. Une nouvelle campagne de communication, nommée « NO2X », a alors émergé pour empêcher cette augmentation de la taille des blocs. Le 8 novembre, le hard fork est finalement abandonné à la dernière minute, faute de consensus et face au rejet de la communauté. Cette date est souvent considérée comme marquant la fin de la Blocksize War.
➤ En savoir plus sur les méthodes d'activation de forks sur Bitcoin.
Conclusion
Cet épisode de la Blocksize War a indéniablement marqué la communauté Bitcoin. Ce qui était au départ un simple débat technique s’est progressivement transformé en un conflit qui aurait pu mettre en péril l’existence même de Bitcoin, ou du moins l’affaiblir considérablement. Cette période a également profondément influencé la manière de concevoir les évolutions du protocole : aujourd’hui, une majorité de bitcoiners préfèrent une approche prudente et conservatrice en matière de mises à jour, en favorisant les soft forks plutôt que les hard forks, même si cela complique le processus. De plus, l’idéologie des small blockers est désormais largement acceptée par les utilisateurs.
La Blocksize War a aussi créé un précédent, en prouvant que l’UASF pouvait être un puissant outil de dissuasion pour permettre aux utilisateurs de préserver leur pouvoir face aux mineurs et aux grands acteurs de l’industrie.
Pour approfondir ce sujet de la Blocksize War, je vous conseille de lire l’ouvrage The Blocksize War de Jonathan Bier, dont je me suis servi pour rédiger cet article.
)
