Guerre de la taille des blocs

Imaginons deux besoins ordinaires. Anna souhaite envoyer du bitcoin sans attendre longtemps ni payer des frais élevés. Pavel fait fonctionner un nœud complet : un ordinateur qui vérifie lui-même blocs et transactions. Il veut contrôler son argent sans matériel coûteux. Les deux attentes sont légitimes, mais davantage de données par bloc signifie aussi davantage de données à transmettre et à vérifier. C’est cet équilibre qui était au cœur de la Block Size War. Un bloc regroupe des transactions ajoutées à l’historique des paiements partagé par le réseau. Anna et Pavel sont des personnages d’illustration. Le véritable débat de 2015–2017 réunissait développeurs, opérateurs de minage, plateformes d’échange, fournisseurs de portefeuilles et utilisateurs. Ils divergeaient sur la capacité, mais aussi sur la manière de changer les règles sans danger. Bitcoin n’avait aucun directeur capable de choisir une option et d’ordonner à tous de l’adopter. [1] [11] [13]

Avant SegWit, les règles limitaient un bloc à 1 MB, soit 1 000 000 d’octets. Ce n’était pas un nombre fixe de paiements : les transactions occupent des espaces différents. Un bloc apparaît environ toutes les dix minutes en moyenne. Lorsque la demande dépasse la capacité, les mineurs privilégient généralement les transactions proposant les taux de frais les plus élevés ; les autres attendent. Les partisans de blocs plus grands souhaitaient ajouter de la place directement sur le réseau de base et préserver des paiements abordables. Leurs opposants s’inquiétaient des besoins en connexion, en ordinateurs et en diffusion rapide des blocs. Si moins de personnes pouvaient vérifier par elles-mêmes, davantage d’utilisateurs dépendraient de services tiers. Augmenter la limite n’accélère pas à lui seul la production des blocs et ne garantit pas des frais durablement bas : la demande et l’utilisation réelle comptent aussi. [1] [2] [13]

Un développeur peut écrire un nouveau logiciel, un mineur l’utiliser pour produire un bloc. Mais l’opérateur d’un Full Node choisit les règles que son nœud vérifie. Même une majorité de puissance de calcul ne peut pas obliger un nœud inchangé à accepter un bloc contraire à ses règles. La puissance contribue au choix entre chaînes valides ; elle ne rend pas valide un bloc invalide. Cela ne donne pas à chaque nœud une voix dans un scrutin mondial, ni à une personne le pouvoir d’empêcher les autres de partir. Les entreprises choisissent ce qu’elles acceptent, les mineurs ce qu’ils minent et les utilisateurs ce qu’ils valorisent. Des règles incompatibles peuvent aboutir à deux réseaux. Un accord commercial pouvait soutenir un changement, pas réécrire automatiquement tous les logiciels et toutes les décisions. [11] [12]

Les propositions étaient documentées sous forme de BIP, pour Bitcoin Improvement Proposal. Un BIP expose une proposition afin que chacun puisse l’examiner et en discuter. Lui attribuer un numéro ne signifie pas que le réseau l’a adoptée. Dans BIP 101, Gavin Andresen proposait une limite de 8 MB, suivie d’une progression prévue à l’avance. Le projet prévoyait un doublement approximatif tous les deux ans et des conditions d’activation. Mike Hearn et Andresen défendaient Bitcoin XT, un logiciel alternatif offrant cette voie. Publier ce programme ne revenait toutefois pas à modifier les règles de l’ensemble du réseau. Les anciens nœuds auraient rejeté un bloc dépassant la limite existante. Il s’agissait donc d’un Hard Fork : un élargissement de l’ensemble des blocs autorisés, nécessitant d’autres règles pour les accepter. Au-delà de la place à ajouter, il fallait savoir qui migrerait, comment coordonner le passage et ce qui se produirait si une part importante des participants refusait. [1] [18] [13]

Eric Lombrozo, Johnson Lau et Pieter Wuille ont décrit une autre approche dans BIP 141. SegWit a réorganisé les données des transactions et introduit le poids des blocs, plafonné à 4 000 000 weight units. La partie appelée witness contient notamment les données permettant de vérifier l’autorisation de dépenser. Elles n’ont ni disparu ni cessé d’être vérifiées : leur traitement dans le calcul du poids a changé. La capacité dépend de la composition des transactions ; il ne s’agit pas simplement d’autoriser des blocs ordinaires de quatre mégaoctets. Le poids indique comment les données comptent dans la limite du bloc : un octet de données de base vaut 4 unités, contre 1 pour un octet supplémentaire lié au witness. Deux transactions de même taille en octets peuvent donc consommer des poids différents. La capacité dépend aussi des types de transactions utilisés. Pour les transactions concernées, SegWit empêche aussi de modifier leur identifiant en altérant les données de signature. Cela facilite les canaux de paiement sur lesquels repose Lightning Network. SegWit a été conçu comme un Soft Fork : les nouveaux blocs valides respectent les anciennes règles, mais les anciens nœuds ne vérifient pas toutes les nouvelles restrictions. Bitcoin Core 0.13.1 incluait le mécanisme d’activation ; la publication du logiciel n’activait pas SegWit à elle seule. [2] [3]

Le 23 mai 2017, Digital Currency Group a publié le New York Agreement, accord entre entreprises et mineurs. Il associait le soutien à SegWit à un Hard Fork vers 2 MB dans les six mois. Cette seconde étape, appelée SegWit2x, était mise en œuvre par le projet btc1. Certains y voyaient un compromis acceptable : chaque camp obtiendrait une partie de ce qu’il demandait. D’autres contestaient la seconde modification et la manière de la promouvoir. L’adhésion d’une entreprise ne valait pas consentement de tous ses clients. Bitcoin Core a ensuite précisé que btc1 n’était pas une mise à jour obligatoire de son logiciel et que soutenir SegWit ne signifiait pas soutenir SegWit2x. Pour lire les nouvelles de l’époque, il faut garder cette distinction : deux changements réunis dans un accord restaient deux changements de règles. [6] [7] [11]

L’auteur pseudonyme Shaolin Fry a proposé BIP 148, une forme de UASF, ou Soft Fork activé par les utilisateurs. À partir du 1er août 2017, selon Median Time Past, les nœuds l’appliquant devaient rejeter les blocs sans signal SegWit, sauf si son activation était déjà verrouillée ou effective. Si le minage et l’acceptation des blocs divergeaient, le réseau pouvait se scinder. Ce n’était pas un interrupteur sans risque actionné collectivement par tous. Median Time Past est la valeur centrale obtenue en classant les horodatages des 11 derniers blocs, et non l’heure affichée par chaque utilisateur. Le signal était une marque dans l’en-tête du bloc exprimant le soutien du mineur à ce déploiement ; il n’activait pas à lui seul les nouvelles règles. Avec BIP 91, James Hilliard décrivait une coordination des mineurs à un seuil inférieur : 269 blocs sur 336, environ 80 %. Une fois le mécanisme en vigueur, les participants devaient rejeter les blocs ne signalant pas le déploiement initial de SegWit. La coordination de juillet a réduit le risque de conflit autour de l’échéance d’août. Elle ne signifiait pas que SegWit était déjà verrouillé ou actif en juillet : il suivait toujours son propre mécanisme BIP 9. [4] [5] [9] [19]

Bitcoin Cash s’est séparé le 1er août 2017. Le logiciel Bitcoin ABC permettait de plus grands blocs sur cette branche, avec une limite par défaut de 8 MB à l’époque. Dès la séparation, les réseaux avaient leurs propres règles et monnaies. Leur histoire commune n’autorisait pas à transférer librement les paiements ultérieurs entre BTC et BCH. Bitcoin Cash n’était pas SegWit2x et Bitcoin ABC n’était pas btc1. Confondre ces noms mélange la scission d’août avec un autre projet suspendu plus tard. Leur replay protection différait aussi : les mesures empêchant qu’une transaction soit rejouée sur l’autre chaîne. Pour l’utilisateur, l’enjeu était concret : une opération sur une branche ne devait pas dépenser involontairement les fonds de l’autre. Il était également dangereux de saisir les clés communes dans n’importe quel outil promettant de nouvelles pièces. [8] [15] [11]

SegWit est entré dans l’état LOCKED_IN au bloc 479 808, le 9 août 2017. La période de décision était achevée ; une période d’attente restait à parcourir avant l’application des nouvelles règles. L’activation a eu lieu au bloc 481 824, le 24 août. Ces hauteurs sont séparées de 2 016 blocs. La coordination BIP 91 de juillet, le verrouillage d’août et l’activation sont donc des événements différents. Il restait la seconde étape de SegWit2x, prévue à la hauteur 494 784. Le 8 novembre, ses organisateurs, emmenés par Mike Belshe, ont annoncé sa suspension : leur communiqué reconnaissait un accord insuffisant pour une transition sans heurts. Bitcoin n’a pas perdu le SegWit déjà actif, et Bitcoin Cash n’a pas disparu. C’est cette tentative précise de convertir le soutien d’entreprises et de mineurs en augmentation de la limite de Bitcoin qui s’est arrêtée. [9] [10] [12] [14] [16] [17]

Le conflit a montré que Bitcoin peut évoluer, mais qu’écrire du code, recueillir des signatures d’entreprises et faire accepter des règles sont des tâches différentes. Il n’a prouvé ni l’absence d’influence des développeurs, ni l’inutilité des mineurs, ni une issue identique pour toutes les décisions futures. Capacité, vérification accessible et accord des participants ne se résolvent pas en renommant une mise à jour. Devant une proposition, demandez d’abord ce qu’elle modifie, quels nœuds seraient en désaccord et comment elle serait activée. Distinguez ensuite proposition, logiciel publié et règles réellement appliquées. Les BIP et le code de l’époque documentent les mécanismes ; les déclarations des différents camps, leurs positions. Aucun communiqué d’un participant n’est, à lui seul, un récit impartial de toute l’histoire. [1] [6] [11] [12]