L'histoire de Bitcoin est jalonnée de mises à jour critiques qui ont défini sa trajectoire en tant que monnaie numérique mondiale. Parmi ces étapes techniques, peu ont été aussi transformatrices ou aussi vivement débattues que la mise en œuvre de Segregated Witness. Souvent désignée par son acronyme SegWit, cette mise à niveau du protocole a été activée en août 2017 après une période de discussions intenses au sein de la communauté et de construction de consensus. Elle a représenté un moment pivotal pour le réseau, en abordant des problèmes de longue date liés à l'évolutivité et à la sécurité.
Avant SegWit, le réseau Bitcoin subissait une pression croissante de sa base d'utilisateurs en expansion. À mesure que l'adoption augmentait, les limitations de la taille originale des blocs sont devenues un goulot d'étranglement, entraînant une congestion du réseau et une hausse des coûts des transactions. Les développeurs et les parties prenantes cherchaient une solution capable d'alléger ces pressions sans compromettre la nature décentralisée de la blockchain. Segregated Witness est apparue comme une solution ingénieuse d'ingénierie qui optimisait la manière dont les données étaient stockées, plutôt que d'augmenter simplement la limite de taille des blocs.
Cette mise à niveau a fait plus que simplement améliorer la capacité. Elle a fondamentalement modifié les mécanismes de traitement des transactions en abordant une vulnérabilité technique connue sous le nom de malléabilité des transactions. En corrigeant ce problème, SegWit a posé les bases nécessaires pour que des solutions de seconde couche comme le Lightning Network puissent prospérer. Cela a ouvert la voie à des paiements instantanés et peu coûteux qui étaient auparavant difficiles à implémenter de manière sécurisée.
Comprendre SegWit nécessite d'aller au-delà des simples spécifications techniques. Cela implique d'examiner le modèle de gouvernance de Bitcoin, l'économie de l'espace des blocs et les dynamiques communautaires qui animent l'évolution du protocole. Cette mise à niveau a démontré que Bitcoin pouvait s'adapter et s'évoluer via des soft forks, en préservant la compatibilité descendante tout en introduisant des améliorations radicales en termes d'efficacité et d'utilité.
Le défi de l'évolutivité
Bitcoin a été conçu à l'origine avec une limite sur la taille des blocs pouvant être ajoutés à la blockchain. Cette limite, fixée à 1 mégaoctet (MB), servait de mesure de protection contre les attaques de spam dans les premiers jours du réseau. Cependant, à mesure que Bitcoin passait d'une expérience obscure à un actif reconnu mondialement, cette fonctionnalité de sécurité est devenue une contrainte à la croissance.
Le goulot d'étranglement de la taille des blocs
Chaque transaction Bitcoin consiste en des données qui doivent être traitées et stockées par les mineurs. Ces données incluent les entrées, les sorties et les signatures numériques qui prouvent la propriété des fonds dépensés. À l'ère pré-SegWit, toutes ces informations devaient rivaliser pour l'espace au sein de la limite rigide de 1 MB par bloc.
À mesure que la popularité du réseau explosait, la demande d'espace dans les blocs dépassait fréquemment l'offre disponible. Les utilisateurs se retrouvaient dans une guerre des enchères, en attachant des frais plus élevés à leurs transactions pour inciter les mineurs à les inclure dans le bloc suivant. Cette dynamique entraînait des temps de confirmation plus lents pour les utilisateurs payant des frais standards.
Pendant les périodes de pointe, le réseau devenait congestionné, rendant impraticables les petits paiements ou les microtransactions. La communauté a reconnu que pour que Bitcoin fonctionne efficacement en tant que réserve de valeur et moyen d'échange, le débit du réseau devait être augmenté. Le débat portait sur la manière d'atteindre cette évolutivité sans sacrifier la sécurité ou la décentralisation.
Le dilemme du hard fork
Une solution proposée au problème d'évolutivité était un hard fork. Un hard fork est un changement radical du protocole qui rend valides des blocs/transactions précédemment invalides, ou vice versa. Dans le contexte de l'évolutivité, cela aurait simplement signifié réécrire le code pour permettre des blocs plus grands, comme 2 MB ou 8 MB.
Cependant, les hard forks comportent des risques significatifs. Ils exigent que tous les nœuds du réseau mettent à jour leur logiciel simultanément. Si une partie de la communauté refuse la mise à jour ou est en désaccord avec le changement, la blockchain peut se diviser en deux chaînes distinctes. Cela s'est produit avec la création de Bitcoin Cash, qui a choisi d'augmenter la taille des blocs via un hard fork.
Les développeurs de Bitcoin Core ont priorisé une approche plus sûre connue sous le nom de soft fork. Un soft fork est une mise à niveau compatible avec les versions antérieures, ce qui signifie que les nœuds exécutant des versions plus anciennes du logiciel peuvent toujours participer au réseau. SegWit a été conçu comme un soft fork pour garantir que le réseau reste unifié tout en apportant les améliorations de capacité nécessaires.
Consensus et gouvernance
Le chemin vers l'activation de SegWit a mis en lumière la nature unique de la gouvernance de Bitcoin. Contrairement aux systèmes centralisés où un leader dicte les changements, Bitcoin repose sur un consensus parmi un groupe diversifié de participants. Cela inclut les mineurs, les développeurs, les opérateurs de nœuds et les utilisateurs finaux.
La proposition pour SegWit, connue sous le nom de Bitcoin Improvement Proposal (BIP) 141, nécessitait un seuil de soutien très élevé des mineurs pour s'activer. Plus précisément, 95 % de la puissance de hachage minière devait signaler sa préparation pendant une période de deux semaines. Ce seuil élevé garantit que les mises à niveau bénéficient d'un soutien écrasant avant d'être imposées, minimisant le risque d'instabilité du réseau.
Comment SegWit fonctionne en profondeur
L'innovation principale de Segregated Witness est suggérée par son nom. « Segregated » signifie séparer, et « Witness » fait référence aux signatures numériques qui vérifient une transaction. Dans les transactions Bitcoin legacy, les données de signature numérique étaient entremêlées avec les données de transaction, occupant une portion significative de l'espace précieux des 1 MB par bloc.
Séparation des données de témoin
SegWit a restructuré le format de transaction en déplaçant les données de témoin (signatures) hors de la structure principale du bloc. Bien que ces données soient toujours enregistrées et validées, elles sont stockées dans une structure séparée qui s'exécute en parallèle avec le bloc de transaction de base. Cette séparation a été la clé pour débloquer plus de capacité sans augmenter techniquement la limite de 1 MB pour les anciens nœuds.
Pour visualiser cela, imaginez un train représentant un bloc Bitcoin. Dans le système legacy, les passagers (détails de transaction) et leurs bagages (signatures) étaient tous entassés dans les mêmes wagons. Le train avait une limite stricte sur le volume qu'il pouvait transporter.
SegWit a efficacement ajouté un wagon de fret spécialisé à l'arrière du train spécifiquement pour les bagages. En déplaçant les lourds bagages hors des wagons passagers, le train pouvait soudainement transporter significativement plus de passagers dans les mêmes compartiments principaux. Les « bagages » voyagent toujours avec le train, mais ils n'occupent plus l'espace premium nécessaire pour les passagers eux-mêmes.
Poids du bloc vs taille du bloc
Pour implémenter ce changement, SegWit a introduit un nouveau concept appelé « poids du bloc ». La mesure ancienne de la taille du bloc en octets simples a été remplacée par un système qui attribue des « poids » différents à différentes parties d'une transaction. Cela a permis au réseau de différencier les données critiques de transaction et les données de témoin.
Dans ce nouveau système, les données de transaction de base sont comptées à leur taille complète, tandis que les données de témoin sont réduites. Plus précisément, les données de témoin pèsent significativement moins que les données de transaction dans le calcul de la limite du bloc. Ce changement a efficacement augmenté la limite de taille du bloc de 1 MB à un théorique 4 MB d'« unités de poids ».
Ce changement a incité les utilisateurs et les fournisseurs de portefeuilles à adopter les adresses SegWit. Les transactions utilisant le nouveau format étaient moins chères à envoyer car elles consommaient moins de « poids » dans un bloc par rapport aux transactions legacy. Cet incitatif économique a aidé à promouvoir l'adoption de la mise à niveau dans l'ensemble de l'écosystème.
Octets virtuels (vBytes)
Avec l'introduction du poids du bloc, le concept des frais de transaction a également évolué. Les frais ont commencé à être calculés en « octets virtuels » (vBytes) plutôt qu'en octets bruts. Un vByte est une unité de mesure dérivée du poids de la transaction.
Puisque les données de témoin sont réduites, une transaction SegWit a une taille en vBytes plus petite qu'une transaction legacy de même taille brute. Cela signifie que pour le même taux de frais (satoshis par octet), une transaction SegWit coûte moins en frais totaux.
Ce gain d'efficacité a été immédiat pour les utilisateurs passés aux portefeuilles compatibles SegWit. Cela a permis au réseau de traiter plus de transactions par seconde, augmentant efficacement le débit sans les dangers associés à un hard fork. Cette optimisation a prouvé que l'ingénierie intelligente pouvait extraire plus de performances de l'infrastructure existante.
Résolution de la malléabilité des transactions
Bien que l'évolutivité ait été la fonctionnalité phare de SegWit, la mise à niveau a résolu un autre défaut technique critique connu sous le nom de malléabilité des transactions. Ce problème hantait Bitcoin depuis ses débuts et constituait une barrière majeure au développement de protocoles avancés de seconde couche.
La malléabilité désigne la capacité d'un tiers à modifier l'identifiant unique (TXID) d'une transaction avant sa confirmation sur la blockchain. Importamment, ce changement pouvait être effectué sans invalider la transaction elle-même ni modifier les détails fondamentaux comme l'expéditeur, le destinataire ou le montant.
Dans le système legacy, la signature numérique était incluse dans le calcul du hachage de la transaction (le TXID). Cependant, les signatures cryptographiques peuvent être représentées mathématiquement de manières légèrement différentes tout en restant valides. Un attaquant ou un nœud relais pouvait modifier légèrement les données de signature, ce qui entraînerait un TXID complètement différent.
Si le TXID changeait, l'expéditeur pouvait croire que la transaction avait échoué, tandis que le destinataire (ou l'attaquant) confirmait la version modifiée. Cela créait de la confusion et rendait dangereux le chaînage de transactions non confirmées. Si la première transaction d'une chaîne avait son ID modifié, toute transaction subséquente référencant cet ID deviendrait invalide.
SegWit a corrigé cela en retirant les données de signature de la partie de la transaction utilisée pour générer le TXID. Puisque le « témoin » était ségrégué, toute modification des données de signature n'affectait plus l'ID de la transaction. Cela rendait l'ID de transaction immuable dès sa création.
Activation du Lightning Network
La correction de la malléabilité des transactions a été le catalyseur du Lightning Network. Le Lightning Network est une solution d'évolutivité de couche 2 qui repose fortement sur la capacité à créer des chaînes de transactions non confirmées de manière sécurisée.
Les bases de la couche 2
Pour que les canaux de paiement fonctionnent, deux parties ouvrent efficacement un compte joint sur la blockchain, puis échangent des transactions signées hors chaîne. Ces transactions hors chaîne mettent à jour le solde du canal sans toucher à la blockchain principale.
Cependant, ces transactions hors chaîne dépendent de la transaction de « financement initial » étant ancrée de manière sécurisée. Si la malléabilité des transactions était encore possible, un acteur malveillant pourrait potentiellement altérer l'ID de la transaction de financement. Cela invaliderait toute la logique hors chaîne subséquente sur laquelle les parties s'étaient accordées.
En sécurisant l'ID de transaction, SegWit a fourni la base solide nécessaire pour ces contrats intelligents. Cela a permis aux nœuds Lightning de faire confiance au fait que les transactions qu'ils signaient hors chaîne resteraient valides lors de leur règlement final sur le réseau Bitcoin principal.
Règlements instantanés
Avec le risque de malléabilité éliminé, le Lightning Network pouvait être déployé en toute sécurité. Cela a permis des règlements de paiements quasi instantanés entre utilisateurs partout dans le monde. Bien que SegWit ait fourni une augmentation modeste de capacité sur chaîne, activer Lightning offrait le potentiel d'une évolutivité hors chaîne virtuellement illimitée.
Les utilisateurs pouvaient désormais transiger des millions de fois sans surcharger la blockchain principale, ne réglant que le résultat final. Cette combinaison d'efficacité sur chaîne (via SegWit) et d'évolutivité hors chaîne (via Lightning) représente la stratégie principale de Bitcoin pour gérer le volume de transactions mondial.
La saga d'activation : BIP 141 et UASF
Le déploiement de SegWit n'était pas simplement une mise à jour technique ; c'était un événement historique dans la gouvernance décentralisée. Le processus a révélé les dynamiques complexes de pouvoir entre mineurs, développeurs et utilisateurs au sein de l'écosystème Bitcoin.
La proposition (BIP 141)
La mise à niveau SegWit a été formellement proposée sous forme de Bitcoin Improvement Proposal 141. Pour une activation fluide, les développeurs ont fixé un seuil nécessitant que 95 % des blocs signalent leur soutien à la mise à niveau au sein d'une époque de difficulté de deux semaines. Cela visait à garantir que le réseau ne se divise pas.
Cependant, atteindre ce consensus s'est avéré difficile. Divers intérêts politiques et économiques parmi les grands pools miniers ont conduit à une impasse. Certains mineurs préféraient un hard fork pour augmenter directement la taille des blocs, tandis que d'autres hésitaient à mettre à niveau leur infrastructure.
Pendant des mois, le signalement d'activation est resté bien en dessous du seuil requis. Il semblait que la mise à niveau pourrait stagner indéfiniment, soulignant un défaut potentiel dans la dépendance au signalement des mineurs pour les mises à niveau du protocole.
User Activated Soft Fork (BIP 148)
Frustrés par le manque de progrès, un mouvement de base a émergé au sein de la communauté. Cette initiative était connue sous le nom de User Activated Soft Fork (UASF), ou BIP 148. Le concept était révolutionnaire : au lieu d'attendre que les mineurs votent, la majorité économique des nœuds (utilisateurs, échanges et entreprises) imposerait la mise à niveau eux-mêmes.
Les participants à l'UASF exécutaient une version du logiciel Bitcoin qui rejetait tout bloc ne signalant pas son soutien à SegWit après une certaine date. Cela traçait efficacement une ligne dans le sable. Si les mineurs continuaient à ignorer SegWit, leurs blocs seraient rejetés par une portion significative du réseau, les faisant perdre des revenus.
La menace d'un User Activated Soft Fork a déplacé l'équilibre des pouvoirs. Cela a démontré que bien que les mineurs traitent les transactions, ce sont les utilisateurs qui définissent les règles du protocole. Confrontés à la pression économique de l'UASF, les mineurs ont capitulé, et SegWit a été verrouillé et activé en août 2017.
Types d'adresses et compatibilité
À la suite de l'activation de SegWit, l'écosystème Bitcoin a vu l'émergence de différents formats d'adresses. Comprendre ces formats est essentiel pour les utilisateurs souhaitant profiter des frais plus bas et des avantages d'efficacité offerts par SegWit.
Adresses Legacy
Le format d'adresse Bitcoin original est connu sous le nom de Legacy. Ces adresses commencent généralement par le chiffre 1. Les transactions envoyées depuis des adresses Legacy sont plus volumineuses car elles n'utilisent pas la séparation des données de témoin. Par conséquent, elles sont les plus coûteuses en termes de frais de transaction.
Nested SegWit (P2SH)
Pour assurer une adoption fluide, les développeurs ont introduit une couche de compatibilité connue sous le nom de Pay to Script Hash (P2SH). Ces adresses commencent par le chiffre 3. Elles permettaient aux utilisateurs d'envoyer des transactions SegWit même si le portefeuille de l'expéditeur ne prenait pas pleinement en charge le nouveau format natif.
Nested SegWit offrait un terrain intermédiaire. Il procurait des économies significatives de frais par rapport aux adresses Legacy, bien que moins importantes que l'implémentation pleinement native. Pendant longtemps, cela a été la norme pour de nombreux échanges et fournisseurs de portefeuilles lors de la mise à jour de leurs systèmes.
Native SegWit (Bech32)
Le format le plus efficace est Native SegWit, également connu sous le nom de Bech32. Ces adresses commencent par bc1. Les adresses Native SegWit sont distinctes car elles sont insensibles à la casse, réduisant le risque d'erreurs de saisie.
Plus important encore, les transactions Native SegWit sont plus petites en octets virtuels que leurs équivalents Nested. Cela résulte en les frais de transaction les plus bas possibles pour les utilisateurs. À mesure que l'écosystème a mûri, Native SegWit est devenu la norme par défaut pour la plupart des portefeuilles et services modernes.
| Type d'adresse | Préfixe | Efficacité des frais | Compatibilité |
|---|---|---|---|
| Legacy | 1... | Faible | Universelle |
| Nested SegWit | 3... | Moyenne | Élevée |
| Native SegWit | bc1... | Élevée | Portefeuilles modernes |
Au-delà de SegWit : Taproot et Ordinals
La mise en œuvre réussie de SegWit a prouvé que Bitcoin pouvait subir des mises à niveau complexes sans perturber sa proposition de valeur principale. Ce succès a ouvert la voie à des innovations subséquentes qui ont encore élargi les capacités du réseau.
Taproot et signatures Schnorr
En novembre 2021, Bitcoin a activé la mise à niveau Taproot. Taproot s'est directement construit sur les bases posées par SegWit. Il a introduit les signatures Schnorr, qui permettaient une efficacité et une confidentialité encore plus grandes.
Comme SegWit, Taproot a modifié la manière dont les données sont stockées sur la blockchain. Il a permis l'agrégation de signatures, où plusieurs signatures dans une transaction complexe pouvaient être combinées en une seule signature. Cela rendait les contrats intelligents complexes indistinguables des transactions régulières, améliorant la confidentialité tout en économisant de l'espace dans les blocs.
Sans les changements structurels introduits par SegWit, spécifiquement le système de versionnement des scripts, des mises à niveau comme Taproot auraient été significativement plus difficiles à déployer. SegWit a établi un chemin clair pour l'extensibilité future.
L'essor des Ordinals
Plus récemment, l'introduction des Bitcoin Ordinals a exploité l'infrastructure SegWit de manières inattendues. Les Ordinals permettent aux utilisateurs d'inscrire des données arbitraires — telles que des images, du texte ou du code — directement sur des satoshis individuels.
Cela est possible car SegWit a réduit le « poids » des données de témoin. Les inscriveurs ont réalisé qu'ils pouvaient stocker de grandes quantités de données dans le champ témoin d'une transaction pour une fraction du coût de les stocker dans la zone principale du bloc. Bien que controversé pour certains qui y voient du spam, les Ordinals ont démontré la flexibilité de l'espace des données de témoin.
Ce cas d'utilisation inattendu met en lumière la nature robuste de la conception SegWit. En créant une voie séparée et réduite pour les données, la mise à niveau a involontairement créé une toile pour les artefacts numériques, diversifiant encore plus l'utilité de la blockchain Bitcoin.
Conclusion
Segregated Witness témoigne de la résilience et de l'adaptabilité du réseau Bitcoin. Face à un goulot d'étranglement critique qui menaçait d'étouffer la croissance, la communauté s'est unie derrière une solution élégante, compatible avec les versions antérieures et visionnaire. En repensant la structure des données de transaction, SegWit a apporté un soulagement immédiat aux frais élevés tout en préservant la décentralisation qui donne à Bitcoin sa valeur.
L'héritage de SegWit va bien au-delà des simples calculs de poids des blocs. Il a résolu la vulnérabilité persistante de la malléabilité des transactions, débloquant le potentiel des solutions d'évolutivité de couche 2 comme le Lightning Network. De plus, il a établi un précédent pour une gouvernance pilotée par les utilisateurs, prouvant que la majorité économique peut efficacement contrôler le pouvoir des entités minières.
À mesure que Bitcoin continue d'évoluer, les structures construites par SegWit restent centrales à son fonctionnement. De l'efficacité des adresses Native SegWit aux capacités avancées de Taproot et Ordinals, la mise à niveau a redéfini ce qui est possible sur la blockchain. Elle a assuré que Bitcoin puisse s'évoluer pour répondre à la demande mondiale sans compromettre les principes sur lesquels il a été fondé.
SegWit a révolutionné Bitcoin en séparant les signatures des données de transaction, augmentant efficacement la capacité des blocs et corrigeant des bugs critiques pour permettre une évolutivité future.