La semaine dernière, Taproot, l’une des mises à jour les plus importantes de l’histoire du bitcoin, a été activée. Mais ce qu’elle apporte concrètement est difficile à comprendre et il n’est pas rare qu’elle soit présentée de manière erronée. Nous avons donc demandé à un expert.
La semaine dernière, Taproot a été activé, l’une des plus importantes mises à jour de Bitcoin de tous les temps, que la communauté attendait avec impatience depuis des années. Mais qu’est-ce que Taproot exactement ? Et que fait-il ?
Si vous lisez l’actualité de Taproot en vous posant cette question, vous risquez de vous retrouver dans une grande confusion. C’est pourquoi cet article commence par un petit tour d’horizon de ce que les autres écrivent
Quand les agences de presse parlent d’une mise à jour de Bitcoin …
L’une des caractéristiques les plus remarquables de Taproot est qu’il s’agit de la première mise à niveau de Bitcoin qui ait valu un article à l’agence de presse DPA. Cela explique pourquoi on trouve soudain des informations sur Taproot dans presque tous les médias, du Süddeutsche et du FAZ à la Gazette des petites villes, en passant par le Wiener Standard. Ou, plus exactement, de la désinformation.
Taproot, explique le site Finanzen.net, a une « signification étendue pour la blockchain Bitcoin ». La mise à niveau rend le bitcoin « encore plus agile et flexible » et « ouvre la voie à d’importantes innovations technologiques ». La FAZ et de nombreux autres journaux citent la dépêche de la DPA selon laquelle la mise à niveau apporte « plus de confidentialité, moins de besoins de stockage et une baisse des coûts ».
Tout cela reste si vague que cela ne peut être ni faux ni vrai. Si l’on veut des informations plus concrètes, on en apprend moins, et si on en apprend, elles sont souvent fausses ou trompeuses. Finances.net affirme ainsi qu’avec Taproot, « au lieu de plusieurs clés publiques […], une seule clé publique est générée lors des paiements », ce qui, si l’on fait abstraction de la confusion des termes, est au mieux à moitié exact. En outre, Taproot permet « des contrats intelligents plus complexes sur la blockchain Bitcoin », raison pour laquelle Bitcoin pourrait bientôt entrer en concurrence avec Ethereum.
Dans la FAZ, on apprend que les signatures Schnorr « garantissent une plus grande sphère privée pour le Bitcoin ». Le journal ou la DPA a demandé une déclaration au professeur de blockchain Philipp Sandner, qui affirme que « grâce à ces transactions de type Schnorr, … un ensemble de transactions est validé par une seule signature ». Même un professeur peut parfois se tromper à tel point que l’on ne sait pas par où commencer.
C’est encore Heise qui informe le mieux sur Taproot. Le magazine informatique explique que la mise à jour introduit le « type de transaction Pay-to-Taproot (P2TR) », « qui réunit les concepts de signatures Schnorr et de ‘Merklized Alternative Script Trees' ». Mais Heise se met lui aussi à flotter lorsque le magazine affirme que Taproot augmente la sphère privée lors des transactions ou que Schnorr permet de signer une transaction avec une signature agréée.
C’est au mieux à moitié vrai et cela montre surtout à quel point il est difficile de comprendre – et d’expliquer – une mise à niveau techniquement sophistiquée comme Taproot.
Une mise à jour comme un wrap
Nous essayons de mettre un peu d’ordre dans le chaos de Taproot. Pour cela, nous avons contacté Mark Erhardt, également connu sur Internet sous le nom de Murch. Mark travaille à New York chez Chaincode Labs, après avoir travaillé pour BitGo à Palo Alto. Il est difficile d’être plus proche des centres de développement du bitcoin que le Badois.
Mark nous a aidés à mieux comprendre Taproot, non seulement sur le plan conceptuel, mais aussi à saisir ce que la mise à niveau signifie concrètement.
Qu’est-ce qui change dans Taproot ? Quels sont les avantages de la mise à jour ?
Taproot se compose grosso modo de deux éléments : Des signatures Schnorr et une arborescence de scripts. Ces deux éléments sont indépendants l’un de l’autre, mais ils interagissent, et chacun d’entre eux n’est pas facile à comprendre. C’est l’un des obstacles pour comprendre ce que fait vraiment Taproot – et ce qu’il ne fait pas.
Schnorr – le meilleur ECDSA
Les signatures Schnorr sont les plus faciles à comprendre. Celles-ci, explique Mark, existaient déjà avant l’algorithme de signature ECDSA utilisé par Bitcoin.
« Le procédé de signature est super intéressant, mais son inventeur, Klaus-Peter Schnorr, l’a fait breveter. Comme les frais de brevet étaient trop élevés, d’autres cryptographes ont inventé ECDSA pour signer également sur la base de courbes elliptiques. Mais entre-temps, la protection du brevet a expiré ».
ECDSA est bon, même très bon, raison pour laquelle Satoshi a choisi cet algorithme pour le bitcoin. Mais il n’est pas tout à fait aussi bon que Schnorr, et sans la protection du brevet, personne n’aurait eu de raison d’utiliser ECDSA plutôt que Schnorr.
La principale différence réside dans un petit détail, mais parfois décisif : « Les signatures ne sont pas linéaires avec ECDSA, alors qu’elles le sont avec Schnorr », explique Mark. « Lorsqu’un schéma de signature est linéaire, il est possible d’agréger plusieurs signatures de manière à ce que l’agrégat permette la vérification. Ce n’est pas possible ainsi avec des schémas non linéaires, comme l’ECDSA ».
En théorie, ce qu’affirment le FAZ et Heise est donc vrai : on pourrait, grâce à Schnorr, regrouper toutes les signatures d’une transaction en une seule. Actuellement, lorsqu’une transaction a beaucoup d’entrées – qu’elle réunit donc beaucoup de coins – il faut signer chaque entrée et écrire chaque signature dans la blockchain. Cela représente une grande partie des données de la transaction. Schnorr pourrait effectivement changer cela.
Pourrait ! Car « cette agrégation n’a malheureusement pas été intégrée dans la mise à jour de Taproot », précise Mark. « Cela aurait nécessité des définitions et des discussions supplémentaires, c’est pourquoi il a été décidé de le faire plus tard. «
Agréger secrètement les signatures
Cependant, Taproot permet déjà d’agréger les signatures de Schnorr. Mais pas pour les transactions normales, seulement pour les transactions multisig. Multisig signifie que deux parties ou plus doivent signer une transaction pour que des coins puissent être émis à partir d’une adresse spéciale (adresse multisig).
« Supposons que nous créions ensemble un portefeuille dans lequel nous ne pouvons dépenser de l’argent que si nous signons tous les deux. Ce serait un ‘2 sur 2 multisig’. Grâce à Taproot, nous pouvons agréger nos clés publiques : Tu me donnes ta clé publique, je l’associe à la mienne, et le résultat est indiscernable d’une adresse normale. On ne peut donc pas reconnaître qu’il s’agit d’un portefeuille partagé ».
Ce « ne pas pouvoir reconnaître » est la raison déterminante pour laquelle on dit que Taproot améliore la vie privée.
Jusqu’à présent, les adresses multi-sigles étaient facilement reconnaissables. Elles commençaient par un trois, et non par un un comme les adresses traditionnelles. SegWit a quelque peu assoupli cette règle, car un format d’adresse SegWit commence également par un 3. Néanmoins, les différents types d’adresses créent des différences qui sapent en partie la confidentialité de Bitcoin.
Taproot permet d’aplanir complètement ces différences. Quelles que soient les conditions de sortie incarnées par une adresse – une signature, plusieurs signatures, timelocks, smart contracts – elles se ressemblent toutes.
Mais pour cela, les signatures Schnorr seules ne suffisent pas. En effet, celles-ci ne s’appliquent qu’aux constructions multisigles simples : « 2 sur 2 », « 3 sur 3 », et ainsi de suite. Dans la pratique, d’autres modèles sont plus appréciés, à savoir les signatures dites de seuil, comme « 2 sur 3 » : Une troisième partie dispose d’une clé de secours et intervient lorsqu’une autre clé est perdue ou arbitre lorsque les deux autres sont en désaccord.
Dans de tels modèles, l’agrégation par des signatures Schnorr ne fonctionne pas. C’est pourquoi nous devons parler ici de la deuxième partie de Taproot : l’arborescence des scripts.
Un arbre de script pour les autres cas
L’ancien employeur de Mark, le fournisseur de portefeuilles BitGo, propose une construction classique « 2 sur 3″ : il y a trois clés. L’une est détenue par le client, l’autre par BitGo, et la troisième est une sauvegarde bien sécurisée, conservée au froid. Sur ces trois clés, il en faut deux pour envoyer une transaction, qui sont généralement celles du client et de BitGo.
Avec la protection BitGo, les fonds des utilisateurs sont totalement en sécurité avec nous, ce qui fait de CoinDCX, l’un des échanges de cryptomonnaies les plus sûrs au monde. BitGo CoinDCX TryCrypto pic.twitter.com/Z4X2tpclix
– CoinDCX : Making Crypto Accessible to Indians (@CoinDCX) Novembre 18, 2021
« Il existe une attente concernant les deux clés qui seront utilisées. On peut maintenant y répondre avec des signatures Schnorr agrégées. Nous formons donc une sortie P2TR avec les clés de toi et de BitGo, et lorsque le cas normal se présente, nous pouvons signer avec une signature agrégée ».
Cette manière de signer les transactions par deux parties est la plus élégante, la plus simple et la plus belle façon de le faire. En comparaison, la méthode actuelle par le biais d’adresses « P2SH » (Pay-to-Script-Hash) est d’une complexité quasi monstrueuse.
Mais que se passe-t-il en cas de sauvegarde ? Si je perds ma clé et que BitGo signe avec la clé de secours ? Ou si BitGo tombe en panne et que je dois mettre en jeu la clé de secours ?
« Ces autres chemins non attendus sont tressés comme des feuilles dans l’arbre de script que Taproot a introduit », explique Mark. Et bien sûr, cette explication appelle à être expliquée elle-même.
Des feuilles aux racines
Un arbre de script est en fait « seulement » un arbre de Merkle ou de Hash avec des scripts. Mais qu’est-ce qu’un arbre de hachage ?
Un arbre de hachage est un arrangement particulier d’une multitude de hachages. Supposons par exemple que nous ayons quatre transactions Bitcoin et que nous formions le hash de ces transactions. Nous aurions alors quatre hashs. Dans un arbre de hachage, on les appelle les « feuilles ».
Le but de l’exercice est de passer des feuilles aux branches et à la racine de l’arbre de hachage. Pour cela, nous commençons par assembler le premier et le deuxième hash et nous hachons cela. Nous faisons de même avec le troisième et le quatrième. Nous hachons également les deux hashs que nous avons comme résultat – les branches. Nous avons ainsi la racine : un hash qui représente une multitude de hashs.
Cet arbre de hachage ressemble à un arbre à l’envers : La couronne est en bas, la racine en haut. Image de wikipedia.org, licence : Creative Commons
Quel est l’intérêt d’une telle racine ? Elle permet de prouver par un seul hash une multitude de données. Un bloc de bitcoin en est un exemple : les mineurs prennent une grande quantité de transactions – en général quelques milliers – et forment à partir de celles-ci la racine de l’arbre de hachage. Cette racine est la base du minage, et elle permet à chacun de vérifier si un bloc est valide.
Dans le scriptbaim introduit par Taproot, chaque « feuille » est une possibilité de dépenser des bitcoins – un script. L’adresse multisig mentionnée ci-dessus ne contient pas seulement l’agrégat de deux clés publiques, mais aussi la racine de l’arbre de script.
Si maintenant le cas non prévu se produit, que je signe avec ma clé et la clé de secours parce que BitGo tombe en panne, voici ce qui se passe, explique Mark:  ; « Je révèle le script correspondant, qui est déposé dans une feuille de l’arbre des scripts. Pour prouver que l’adresse d’origine encode ces conditions de sortie, je révèle les hachages d’autres feuilles et branches, de sorte que la racine puisse être reconstruite. Ensuite, je remplis le script contenu dans la feuille avec les signatures des deux clés ».
Nous avons donc une procédure dans laquelle les transactions multisig se déroulent généralement – lorsque le cas attendu se produit – de manière plus élégante, plus simple et aussi plus privée. Ce n’est que dans les cas non attendus que l’arborescence de scripts intervient. Le résultat est aussi complexe que la méthode P2SH – mais il est un peu plus privé.
En effet, avec P2SH, l’ensemble du script est haché et contient toutes les possibilités de dépenser des coins. Pour écrire une transaction valable, je dois présenter le texte pur du script. Je dois donc rendre publiques les clés publiques impliquées, même si elles ne sont pas utilisées.
Avec P2TR, en revanche, il suffit que j’écrive en clair dans la transaction la possibilité qui se produit effectivement. Toutes les autres options restent voilées.
La percée du multisig
Il n’est pas nécessaire de discuter de l’élégance de Taproot. C’est le cas. L’arborescence de scripts est un complément utile aux signatures Schnorr. Il est compréhensible qu’un développeur comme Mark soit enthousiaste à propos de Taproot et qu’il soit impatient de voir la mise à niveau arriver dans tous les portefeuilles.
Mais ceux pour qui l’élégance technique n’est pas une fin en soi, mais un moyen, devraient maintenant se demander : à quoi cela sert-il en vrai ? En d’autres termes, qu’est-ce que Bitcoin peut faire de mieux avec Taproot qu’avant ?
« Multisig est un standard beaucoup plus sûr pour gérer l’argent », dit Mark. « Vous pouvez faire des sauvegardes et rendre plus difficile la dépense d’argent. Cela vous rend moins vulnérable ».
Mais jusqu’à présent, les procédures multisig avaient des inconvénients majeurs : elles étaient souvent complexes, tant pour l’utilisateur que pour les développeurs, elles limitaient la vie privée et coûtaient plus cher. Tous ces inconvénients disparaissent avec Taproot. « On donne moins d’informations privées, on révèle moins de choses sur sa configuration, et on peut faire plus avec moins de données sur la blockchain ».
Mark espère que Taproot aidera Multisig à percer. Que davantage de portefeuilles introduiront le multisig, qu’il y aura de meilleures normes et que l’expérience utilisateur, qui est actuellement souvent grotesque, s’améliorera.
Ce que Taproot ne fait pas
Malgré tout son enthousiasme, Mark met en garde contre les attentes exagérées et erronées. Cela nous ramènerait au point de départ. Avec la dépêche DPA et son interprétation dans les salles de rédaction.
« On dit parfois que Taproot amène DeFi à Bitcoin parce qu’il permet les smart contracts. C’est faux. Les smart contracts existent déjà, et tout ce que Taproot peut faire était déjà possible avant – c’était juste plus compliqué, plus cher et moins privé ».
Quelques idées fausses circulent également sur la sphère privée avec Taproot. « Hier, j’ai lu dans un grand journal allemand que le bitcoin deviendrait plus anonyme grâce à Taproot. Cela aussi est faux. On ne peut certes plus voir si une ou plusieurs parties signent. Mais l’adresse reste un pseudonyme et on peut toujours voir quels coins sont émis. «
Bitcoin est une technologie vieille de 13 ans !
Elle est bloquée, lacunaire en privacy et fungibility, lente et cumbersome.
Essayer de corriger ses défauts de conception avec des kludges de couche 2 est une plaisanterie 🤡EpicCash est lean, agile, private blockchain – tout sur la couche 1 💪😎🚀LightningNetwork Taproot BTC Crypto pic. twitter.com/gBeDqIKvut– EpicCashOfficial (@EpicCashTech) Novembre 24, 2021
Les analystes de la blockchain n’auront aucun problème à analyser et à clusteriser les portefeuilles et les adresses comme auparavant, même après Taproot. « On en apprend juste un peu moins sur la configuration sous le capot. On ne voit plus s’il s’agit d’une adresse normale, d’un canal Lightning ou d’une configuration multisig. Mais la traçabilité générale du flux d’argent reste la même. «
no, tout ce que font les anciens ne sera pas construit « sur Bitcoin ».
RSK, Stacks etc ne sont pas « sur Bitcoin ».
et Lightning, RGB, DLCs, Taproot etc ne peuvent pas vraiment _do_ beaucoup
et non, tous les coins ne sont pas « moins d’argent dur ». la plupart des coins/tokens émis aujourd’hui n’essaient même pas d’être de l’argent.
welcome to 2021
Sry
– eriverse (@ercwl) September 23, 2021
La balle est maintenant dans le camp de l’écosystème
Comme souvent avec Bitcoin, il faut un certain temps pour qu’une mise à niveau se répercute sur les portefeuilles et les utilisateurs. Il suffit de penser à SegWit. La mise à niveau a mis du temps à s’étendre à une grande partie des transactions, et encore plus longtemps avant que le support des adresses bech32 ne soit largement déployé.
Murch espère que les choses iront plus vite avec Taproot. « Les portefeuilles BitGo peuvent déjà recevoir des coins avec Taproot. Cela montre que les choses peuvent aller plus vite cette fois-ci ».
Pour comprendre de quoi il s’agit et pourquoi ce n’est pas si simple, il faut connaître quelques autres détails techniques. Au risque de vous submerger, nous devons parler des formats d’adresse impliqués.
- Les adresses standard sont appelées « Pay-to-Public-Key-Hash » (P2PKH) et commencent par un 1.
- Les adresses « Pay-to-Script-Hash » (P2SH), dont nous avons déjà parlé, commencent par un 3. Elles ont été utilisées pour Multisig et d’autres Smart Contracts comme les Time-Locks.
- Le SegWit s’est également construit au départ sur des adresses commençant par un 3 : Les « Nested SegWit Adresses » ou – désolé : « Pay to Script Hash Pay to Witness Public Key Hash » (P2SH-P2WPKH). Ici, le script a été plus ou moins haché pour SegWit et transformé en une adresse P2SH. Ainsi, SegWit a pu être introduit de manière moins disruptive.
- Les adresses natives SegWit v0, ou encore les adresses Pay to Witness Public Key Hash (P2WPKH), qui fonctionnent techniquement plus efficacement, utilisent le format bech32. Cette norme récemment développée a une apparence totalement différente, les adresses sont plus longues, ne comportent que des lettres minuscules et commencent par « bc1 ».
Le Pay-to-Taproot (P2TR) utilise également le standard bech32. Il y a toutefois une petite différence dans la génération des adresses, ce qui explique que les adresses v0 utilisées jusqu’à présent ne sont pas compatibles. C’est intentionnel, afin d’éviter que quelqu’un ne perde de l’argent.
« Lors de la préparation de Taproot, nous avons découvert que certains portefeuilles ignoraient la version de Witness dans les adresses bech32 et définissaient toujours les sorties comme Native-Segwit-v0 », explique Mark.  ; « Si l’un de ces portefeuilles avait envoyé de l’argent à une adresse P2TR, le script P2TR aurait bien été encodé dans la sortie, mais à cause de l’erreur de version, il aurait fallu remplir un script P2WPKH pour sortir. Le destinataire n’aurait plus pu le dépenser ».
Pour Mark, il est donc important que, dans un premier temps, le plus grand nombre possible de portefeuilles permettent d’envoyer de l’argent à des adresses Taproot. Car tant que cela ne sera pas largement possible, il sera toujours désavantageux pour les utilisateurs d’utiliser ces adresses.
Les développeurs de base ont fait leur travail. Mais le travail pour l’écosystème ne fait que commencer à ce stade.
