Qu'est-ce que SegWit ? Explication technique

SegWit (abréviation de Segregated Witness) est une mise à niveau rétrocompatible du protocole Bitcoin (à savoir un soft fork) qui modifie en profondeur la structure des transactions en déplaçant les données de signature (le témoin ou witness) dans une base de données séparée (segregated). Elle a pour but principal de corriger la malléabilité des transactions, mais elle permet également d’augmenter la capacité transactionnelle de Bitcoin, d’améliorer la vérification des signatures et de faciliter les modifications futures du protocole.

En terme d'ancienneté, SegWit n'est pas une idée nouvelle : la mise à jour a été proposée pour la première fois au cours de l'année 2015, avant d'être formalisée en décembre 2015 par Pieter Wuille et d'autres développeurs de Bitcoin Core. Cependant, elle n'a été mise en place que bien plus tard en raison de son caractère controversé et du rejet des mineurs. Ce n'est qu'en 2017, dans le cadre du compromis SegWit2X, que la proposition autorisant SegWit (BIP-91) a été verrouillée. L'activation de SegWit sur le réseau Bitcoin a finalement eu lieu le 24 août 2017 au bloc 481 824.

On présente ici SegWit dans le cadre du protocole Bitcoin mais il gardez à l'esprit qu'il est possible d'implémenter cette mise à jour au sein de protocoles similaires à Bitcoin : c'est ce qu'ont fait par exemple Litecoin, Decred, Vertcoin et Bitcoin Gold.

Une correction de la malléabilité des transactions

La principale amélioration qu'apporte SegWit est le fait qu'elle corrige le problème de la malléabilité des transactions. Cette correction de la malléabilité facilite grandement l'implémentation des canaux de paiement qui forment la base du réseau Lightning. Elle améliore également l'usage de certains contrats autonomes comme les atomic swaps.

Qu'est-ce que la malléabilité ?

Comme vous le savez peut-être, dans Bitcoin chaque transaction possède un identifiant (txid) représenté sous la forme d'une chaîne de caractères hexadécimaux. Par exemple, l'identifiant de la première transaction réalisée entre Satoshi Nakamoto et Hal Finney est :

f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

Cet identifiant est une empreinte de la transaction, c'est-à-dire le résultat de l'application d'une fonction de hachage à cette transaction. Il dépend donc des éléments présents dans la transaction (entrées, sorties, etc.) : si l'on modifie l'un de ces éléments, l'identifiant se retrouve complètement changé.

Dans Bitcoin, les transactions classiques sont malléables, c'est-à-dire qu'il est possible de modifier leur identifiant sans les invalider. Comment cela est-il possible ? Cela est rendu possible à cause du fait que les signatures qui rendent valide la transaction ne couvrent pas toutes les données. En effet, la transaction est d'abord construite sans les signatures, elle est ensuite signée et enfin les signatures lui sont ajoutées.

On distingue deux formes de malléabilité :

• La malléabilité intrinsèque de l'algorithme de signature lui-même (ECDSA). Ce dernier utilise un nombre aléatoire pour produire une signature : il suffit donc de produire une signature avec un autre nombre aléatoire pour changer l'identifiant de la transaction. Bien évidemment, seul le signataire peut procéder à ce type de manipulation.
• La malléabilité provenant des scripts de déverrouillage (scriptSig) qui contiennent les signatures et qui permettent de débloquer effectivement les fonds présents à une adresse. En effet, il est possible de produire plusieurs scripts différents totalement valides pour la même transaction. Cela veut dire que n'importe qui peut modifier l'identifiant d'une transaction avant qu'elle soit incluse dans un bloc : c'est ce qu'on appelle la malléabilité par un tiers.

Comment corriger cette malléabilité ?

Même si elle n'est pas rédhibitoire, la malléabilité des transaction peut se révéler problématique dans certaines situations. Des propositions ont tenté de corriger la malléabilité par un tiers (BIP-66, BIP-62). Cependant, elles ne permettaient pas de se débarrasser de la malléabilité issue des signatures. C'est dans ce contexte qu'est intervenu SegWit.

Pour procéder à une correction complète de la malléabilité, SegWit déplace simplement les scripts de déverrouillage contenant les signatures dans une structure de données séparée qui accompagne la transaction appelée témoin. Le calcul de l'identifiant (txid) ne prend alors plus en compte ce témoin séparé (Segregated Witness) et devient immuable, ce qui résout le problème.

Un second identifiant (noté wtxid pour witness transaction identifier) est créé pour recouvrir l'entièreté de la transaction. Cet identifiant est inclus avec tous les autres identifiants similaires dans un second arbre de Merkel, dont la racine est placée dans la transaction de récompense (coinbase) du bloc, ce qui fait que l'arbre global englobe encore toutes les données et que personne ne puisse modifier les transactions sans recalculer la preuve de travail.

Puisqu'il s'agit d'un soft fork, les transactions privées de leur témoin et les blocs qui correspondent restent valides pour les nœuds qui suivent les anciennes règles, même si une partie des informations leur échappe. Les nœuds à jour ont eux une vision d'ensemble et peuvent interpréter la nouvelle structure.

Une augmentation de la capacité transactionnelle

Outre la correction de la malléabilité des transactions, la mise à jour SegWit a un autre effet bénéfique majeur : elle permet d'augmenter la capacité transactionnelle du réseau tout en évitant de procéder à un hard fork, comme le requerrait une augmentation de la taille limite des blocs. Cette augmentation est rendue possible grâce au déplacement des scripts de signature en dehors des blocs traditionnels.

Avec SegWit, une nouvelle métrique est mise en place pour mesurer l'impact des transactions et des blocs sur le réseau : le poids (weight). En effet, plutôt que se baser sur la taille d'une transaction qui est exprimée en octets (o) et qui représente la quantité de donnée stockée sur la chaîne de blocs, SegWit utilise un attribut virtuel appelé poids, qui est exprimé en unité de poids (WU) et qui est défini comme :

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

Il s'agit donc d'une moyenne pondérée de la taille de base (c'est-à-dire la taille de la transaction sans le témoin) et de la taille du témoin.

Cette mise à jour transforme la limite de 1 Mo sur la taille des blocs en une limite leur interdisant de dépasser 4 MWU. Il ne s'agit pas pour autant d'une multiplication par 4 de la capacité du réseau. Car, bien que cette nouvelle règle autorise virtuellement la taille totale du bloc SegWit à tendre vers 4 Mo, il faudrait pour cela que ce bloc contienne un petit nombre de transactions possédant chacune un témoin anormalement lourd.

En supposant une adoption totale de SegWit, on pourrait s'attendre plutôt à une augmentation de la capacité transactionnelle du réseau allant de 70 à 100 %, c'est-à-dire à des blocs SegWit dont la taille totale pourrait aller de 1.7 à 2 Mo, ce qui pourrait dans le meilleur des cas permettre de traiter de 5 à 15 transactions par seconde.

Cette nouvelle mesure offre enfin une réduction conséquente des frais pour les transactions SegWit, ce qui permet d'en inciter l'usage. Avant SegWit, les frais étaient mesurés en fonction de la taille de la transaction : plus votre transaction prenait de la place, plus il fallait payer de frais. À présent, ces frais sont mesurés par rapport au poids de la transaction : en effet, le poids devenant le facteur limitant du bloc, les mineurs sont incités à inclure les transactions possédant un bon ratio entre ses frais et son poids.

D'autres améliorations

Conformément au BIP-143, l'algorithme de signature a été amélioré pour les transactions SegWit. D'une part, il permet d'éviter les hachages redondants lors de la vérification d'une signature (le nombre de hachage évoluant alors de manière linéaire, et non plus de manière quadratique). D'autre part, en prenant en compte les montants en entrée de la transaction, l'algorithme offre une meilleure sécurité à la signature hors-ligne utilisée par les portefeuilles matériels comme le Ledger Nano S.

SegWit apporte également un versionnage des scripts, ce qui fait de cette mise à jour un outil d'amélioration du protocole. La version actuelle est la version 0, mais on peut s'attendre prochainement à une version 1 qui activera sans doute les signatures de Schnorr et Taproot, une solution améliorant la flexibilité et le confidentialité des contrats autonomes.

De nouvelles adresses ont également vu le jour avec SegWit. Tout d'abord, il y a 2 nouveaux types « natifs » d'adresse : le Pay-to-Witness-Public-Key-Hash (P2WPKH) et le Pay-to-Witness-Script-Hash (P2WSH), qui sont les équivalents des types P2PKH et P2SH pour SegWit. Ces adresses utilisent un format appelé bech32 : elles sont exprimées en base 32, plus adaptée aux codes QR, et commencent par bc1. Par exemple, une adresse P2WPKH aura la forme suivante :

bc1qe9s87yw62zu5qe7873x3zh3ahhls7677k4y5jt

Puisque la mise à jour a été implémentée comme un soft fork, elle a dû rester compatible avec les anciennes adresses. C'est pour cette raison qu'il fallu concocter des adresses faisant la transition. Pour ce faire, SegWit utilise l'équivalent des types P2WPKH et P2WSH encapsulés dans des adresses P2SH : ces 2 types sont appelés P2SH-P2WPKH et P2SH-P2WSH et sont des types à part entière. Bien évidemment, ils sont compatibles avec tous les portefeuilles Bitcoin. Un exemple d'adresse P2SH-P2WPKH est :

3KspPat3qWB1eFrxSLqCv6e4ozuxB9Bkya

SegWit apporte donc 4 nouveaux types d'adresses.

Des inconvénients majeurs

Contrairement à ce qu'on pourrait penser, SegWit n'est pas du tout un changement mineur apporté à Bitcoin : c'est une restructuration profonde des transactions qui apporte son lot de complications. Même si la mise à niveau a été implémentée grâce à un soft fork, cela ne veut pas dire qu'elle se soit faite en douceur. En effet, une fois SegWit activée, tous les mineurs ne respectant pas les nouvelles règles voyaient leurs blocs rejetés par le réseau : la mise à jour n'était donc pas optionnelle pour les mineurs !

De plus, SegWit ne faisait pas l'unanimité dans la communauté de Bitcoin. Les partisans de la scalabilité on-chain, les mineurs et les gros acteurs du marché y étaient globalement opposés. Et certains membres de la communauté faisaient pression pour l'activer le 1^er août 2017 via un « User Activated Soft Fork ». La mise à jour SegWit ne s'est faite que dans le contexte du compromis amené par SegWit2X, un accord qui voulait activer SegWit tout en augmentant la limite sur la taille de base des blocs à 2 Mo mais qui n'a finalement pas tenu.

D'un point de vue technique, le principal défaut de SegWit est qu'elle apporte avec elle une dette technique énorme ! SegWit complexifie profondément le code de base en amenant par exemple une nouvelle interprétation des scripts liés aux nouvelles adresses. Cela est problématique car Bitcoin est un système économique dont la sécurité repose sur l'audit d'un grand nombre de personnes et se doit d'être simple dans sa conception.

SegWit entraîne aussi une « relaxe de la validation » pour les nœuds suivant les anciennes règles : ceux-ci ne voient pas les signatures et ne les valident pas, ce qui dégrade la qualité du réseau et force les nœuds intéressés à se mettre à jour.

Le dernier inconvénient majeur de SegWit est que son adoption est lente et limitée. Puisqu'il s'agit d'un soft fork, les gens ont le choix d'utiliser SegWit ou non, mais cela impacte directement les promesses faites par cette mise à jour. Actuellement, l'adoption de SegWit stagne autour des 35 %, c'est-à-dire qu'environ 35 % des transactions comprennent au moins une entrée provenant d'une adresse SegWit (P2WPKH, P2WSH, P2SH-P2WPKH ou P2SH-P2WSH). Le fait que ce taux n'approche pas des 100 % entraîne que :

• L'augmentation de la capacité du réseau n'est pas si élevée : la taille moyenne des blocs reste autour des 1.2 Mo lors des pics d'utilisation.
• L'optimisation de la vérification des signatures apportée par le BIP-143 est partielle, ce qui ne résout pas complètement le problème du hachage quadratique.
• Les nouvelles adresses aggravent l'expérience des utilisateurs et amoindrit la confidentialité des transactions.

Ainsi, SegWit est une mise à niveau du protocole Bitcoin apportant son lot d'améliorations. Elle permet notamment de corriger le problème de malléabilité des transactions qui rendait difficile l'implémentation du réseau Lightning et d'augmenter la capacité du réseau. Le fait qu'il s'agisse d'un soft fork rend SegWit compatible avec les anciennes versions de Bitcoin, mais SegWit est loin d'être parfaite : elle souffre de défauts majeurs qui viennent compenser cette rétrocompatibilité, comme sa dette technique qui est conséquente.

Je suis fasciné par les cryptomonnaies et par l’impact qu’elles pourraient avoir sur nos vies. De formation scientifique, je m’attache à décrire leur fonctionnement technique de la façon la plus fidèle possible. Sur Cryptoast, je me propose de vous aider à mieux comprendre comment fonctionnent les cryptomonnaies (principalement Bitcoin, Bitcoin Cash et Ethereum) et quels sont les enjeux qui animent cet écosystème fascinant.

Ludovic Lars

65 articles

Tous ses articles