Bitcoin Taproot Explainer – Bitcoin Magazine : Actualités, articles, graphiques et guides sur le bitcoin
Les signatures Taproot et Schnorr sont mises en ligne sur Bitcoin au bloc 709 632. Il s’agira d’une réalisation fondamentale massive sur laquelle nous pourrons continuer à nous appuyer à l’avenir. Cela fait quatre ans que Segregated Witness a été mis en service sur le réseau, notre dernière mise à jour majeure du protocole. C’est aussi long que le cycle d’un demi-frère !
Pensez-y. Quatre ans entre le lancement de SegWit et le lancement de Taproot. Une patience lente et méthodique, comme il se doit. Mais l’histoire de Taproot/Schnorr remonte à bien plus loin que cela.
L’histoire de Taproot
Certains qui sont ici depuis un certain temps trouveront peut-être cela ironique, mais la première mention des signatures Schnorr dont j’ai connaissance venait en fait de l’ancien développeur Bitcoin Core devenu constructeur de blockchain d’entreprise Mike Hearn. En 2012, il a évoqué l’idée d’une nouvelle courbe cryptographique en relation avec la vérification par lots des signatures afin de rendre la validation des nœuds moins coûteuse en termes de calcul. En fin de compte, le schéma qu’il proposait dépendait des signatures Schnorr.
Adam Back a discuté de l’idée d’une courbe naïve schémas pour faire des adresses multisig qui ressemblaient à des adresses singlesig en 2014, en utilisant des signatures Schnorr. Même Gavin Andresen a inclus Schnorr au lieu de ECDSA sur sa liste de changements qu’il souhaiterait apporter à Bitcoin s’il pouvait agiter une baguette magique.
Depuis le tout début de Bitcoin, la plupart des développeurs activement impliqués dans Bitcoin Core ont souhaité des signatures Schnorr, et il y a toujours eu un consensus assez solide sur leur supériorité par rapport aux signatures ECDSA. On pourrait en fait affirmer que l’ECDSA a été créé spécifiquement parce que le schéma de signature Schnorr était breveté, et qu’il y avait un besoin massif d’un schéma de signature cryptographique open-source non encombré de brevets.
Schnorr est beaucoup plus efficace et facilement manipulable (des éléments peuvent être ajoutés, soustraits, etc. des signatures, et si cela est fait correctement, les utilisateurs peuvent toujours avoir des signatures valides alors qu’ils devraient en avoir) que ECDSA. L’utilisation d’ECDSA était une question de nécessité plutôt que de désir dans la plupart des applications cryptographiques au fil des ans.
Merkelized Abstract Syntax Trees (MAST), la moitié de Taproot de cette prochaine mise à jour de Taproot, a une longue histoire similaire. Je ne suis pas en mesure de trouver la citation, mais je me souviens très bien d’avoir vu cette phrase lancée par des gens comme Peter Todd sur Bitcointalk.org en 2013 ou 2014.
L’original BIP pour MAST a été proposé par Johnson Lau en 2016. Cette proposition a également connu une certaine activité vers 2017 lorsque Mark Friedenbach, BTCDrak et Kalle Alm l’ont divisée en deux BIP distincts (116 et 117) et a développé la proposition originale de Lau.
MAST est resté dans les limbes l’année suivante, jusqu’à ce que Greg Maxwell ait l’idée initiale de Taproot et que le projet soit lancé. publié sur la liste de diffusion bitcoin-dev. Son idée maîtresse était que dans tous les cas de contrats entre plusieurs participants auxquels il pouvait penser, il existait un « résultat optimal » où le contrat pouvait être réglé par la simple signature du résultat approprié au lieu d’appliquer le résultat avec des scripts et des transactions plus avancés. C’est l’affirmation fondamentale sur laquelle repose Taproot, c’est-à-dire la modification de l’arbre MAST en une clé régulière de premier niveau qui peut être dépensée sans révéler si un arbre de Merkle d’autres conditions de dépense existe même.
La dernière partie de cette leçon d’histoire commence avec l’annonce de Pieter Wiulle. des projets de PIF pour Schnorr et Taproot en tandem à la liste de diffusion le 6 mai 2019. En janvier 2020, ces projets ont été formellement finalisés en BIPs 340, 341 et 342. À partir de là, il n’y a eu qu’une multitude de petits détails à peaufiner au niveau de la mise en œuvre, une période de révision, puis la longue bataille sur les mécanismes d’activation. Ce qui nous amène à l’heure actuelle, juste à la limite de l’activation.
L’importance des signatures de Schnorr
Alors, quel est le problème des signatures Schnorr ? Eh bien, pour commencer, elles réduisent la taille des transactions. La taille d’une signature ECDSA est généralement d’environ 72 octets pour une signature unique dans une transaction. La taille maximale des signatures Schnorr est de 64 octets par signature. Cela représente une économie de taille d’environ 12 % par rapport à ECDSA pour chaque signature Schnorr. Il s’agit d’un avantage direct pour la personne qui utilise Schnorr, qui paiera moins de frais qu’un utilisateur d’ECDSA, mais aussi d’un avantage direct pour les personnes qui n’utilisent pas Schnorr, car il faut stocker un peu moins de données dans la blockchain pour traiter et valider les signatures Schnorr de quelqu’un d’autre.
Stocker moins de données est toujours une bonne chose, mais ce qui est encore mieux, c’est d’augmenter l’efficacité de la validation des données que vous devez stocker. L’une des propriétés intéressantes de Schnorr, la linéarité des mathématiques qui le sous-tendent, permet également d’obtenir une propriété intéressante pour les données Bitcoin : la validation par lots. Lorsque votre nœud reçoit un bloc du réseau, il analyse chaque transaction individuelle et valide chaque signature une par une.
C’est en grande partie la raison pour laquelle la validation des blocs consomme beaucoup de puissance CPU. Les signatures Schnorr peuvent être regroupées et validées mathématiquement en une seule fois, un peu comme si on les écrasait et qu’on faisait une seule opération mathématique au lieu de plusieurs. Ainsi, plus il y a de signatures Schnorr, plus les économies de calcul sont importantes. Il s’agit d’un gain d’échelle massif pour le réseau.
Une autre amélioration importante apportée par Schnorr concerne les scripts multisignatures. Chaque adresse multisig doit révéler explicitement toutes les clés publiques individuelles impliquées dans un script multisig au moment de la dépense, et une signature doit être fournie pour chaque clé impliquée dans le processus de dépense. Grâce aux propriétés mathématiques de Schnorr, la porte s’ouvre sur MuSig, une norme de multisignature. Il suffit d’additionner les clés pour obtenir une seule clé publique pour laquelle les parts de clés privées de chacun peuvent être signées à l’aide de nouveaux protocoles de signature. Jonas Nick de Blockstream benchmarké MuSig2 prend deux minutes pour un million participants à une adresse multisig pour signer. L’amélioration de l’échelle des scripts de multisignature ne peut être sous-estimée.
Cet énorme bond en avant pour les scripts multisignatures a également une énorme implication pour le profil de confidentialité et le coût de nombreuses applications construites au-dessus de Bitcoin. Les canaux Lightning basés sur MuSig peuvent maintenant se fondre dans l’ensemble de l’anonymat des UTXO Schnorr/Taproot sur la chaîne car personne ne pourra plus distinguer le fait qu’il s’agit d’une sortie multisignature deux à deux.
Ils se fondront dans la masse et ressembleront à un script à signature unique. Il en va de même pour tout UTXO multisig en général. Cela aura beaucoup d’implications pour les personnes qui utilisent des scripts multisignatures pour mieux protéger leur stockage à froid avec un modèle de sécurité et de récupération plus robuste qu’un script à signature unique.
Tout d’abord, il ne sera pas évident qu’ils utilisent une configuration multisig en observant la blockchain, ce qui, comme dans le cas de Lightning, les fera se fondre dans le décor. Un gain important est cependant lié à l’économie : l’utilisation de la multisignature nécessite actuellement de fournir une signature séparée pour chaque clé impliquée dans la dépense éventuelle d’un UTXO. Avec Schnorr/MuSig, les choses seront comprimées en une seule signature pour la seule clé publique combinée, ce qui signifie que dépenser des UTXO multisignature en utilisant MuSig deviendra beaucoup moins cher, car cela pousse moins de données vers la blockchain.
Une dernière chose cool que les signatures Schnorr font est de simplifier radicalement la mise en œuvre des signatures d’adaptateur. Pensez à une signature d’adaptateur qui est « cryptée » par une valeur qui a été ajoutée ou soustraite d’une signature valide. Elle n’est pas valide tant que vous n’avez pas inversé cette opération mathématique, ou que vous ne l’avez pas « décryptée » avec la « clé » utilisée pour la manipuler. C’est possible avec ECDSA, mais comme les mathématiques ne sont pas linéaires par rapport à Schnorr, c’est relativement compliqué et il y a beaucoup de problèmes de sécurité à prendre en compte dans sa mise en œuvre.
En raison des propriétés linéaires de Schnorr, une signature d’adaptateur est aussi simple que de prendre un simple (disons, le nombre 9 300 030) et d’en soustraire une valeur (disons 30). Une fois que la partie qui détient la signature de l’adaptateur a pris connaissance de la valeur soustraite, elle peut simplement la rajouter et voilàils ont à nouveau une signature valide.
Les implications de Taproot
Comme discuté un peu plus haut, Taproot en réalité est essentiellement juste MAST, sauf qu’au lieu de fonctionner comme P2SH (où vous hachurez le script, ou dans le cas de MAST, la racine Merkle du sommet de l’arbre du script), vous « tweakez » une clé publique Schnorr par la racine de l’arbre Merkle.
La modification fonctionne grâce aux propriétés linéaires de Schnorr – lorsque vous modifiez une clé publique avec une racine de Merkle (en ajoutant cette racine de Merkle à la clé publique), vous pouvez simplement ajouter la racine de Merkle à la clé privée originale et générer la clé de dépense pour la nouvelle clé publique modifiée. En d’autres termes, vous ajoutez la même chose aux deux clés, publique et privée, et elles constituent toujours une paire de clés valide. Cela masque l’existence d’un arbre MAST, à moins qu’une branche de celui-ci ne soit utilisée, mais fondamentalement, il s’agit toujours d’un arbre MAST, mais il est engagé d’une manière plus efficace et plus privée.
La possibilité de s’engager sur différents scripts de dépenses dans un arbre de Merkle et de ne révéler que le script utilisé est un gain d’évolutivité massif en termes de complexité des contrats intelligents qu’il est possible de construire sur Bitcoin.
Tout comme la taille des blocs limite le nombre de transactions par bloc, la taille des transactions est limitée à 100 kilo-octets. La seule différence est qu’au lieu d’être une règle de consensus, c’est une règle de politique. Cela signifie qu’un mineur peut extraire une transaction supérieure à 100 kilo-octets, mais par défaut, aucun nœud du réseau ne relaiera une transaction supérieure à cette limite au mineur en premier lieu.
Cela limite intrinsèquement la taille du script utilisé pour verrouiller un UTXO Bitcoin. Même avec P2SH, où l’UTXO est verrouillé à un hachage du script qui n’est pas révélé avant que vous ne le dépensiez, vous devez toujours révéler le script complet au moment de dépenser. Taproot augmente cette limite d’évolutivité du script en ne vous obligeant pas à révéler l’intégralité du script lorsque vous l’utilisez. Au lieu que la taille totale de toutes les façons dont vous pouvez dépenser l’UTXO soit limitée à la taille limite de la transaction, vous devez seulement vous assurer que chaque façon de dépenser un UTXO Taproot respecte cette limite.
Taproot offre également de nombreux avantages en matière de confidentialité. L’un des grands avantages d’un arbre MAST est la possibilité de créer toutes sortes de situations conditionnelles où les pièces peuvent être dépensées par d’autres parties.
Imaginez des choses comme des systèmes d’héritage où, après un an environ, vos enfants peuvent dépenser vos pièces, ou dans le cas où vous refusez de signer, votre femme et un avocat ont un chemin potentiel pour récupérer les pièces. Rien de ces conditions de dépense n’est révélé au public, sauf si elles sont effectivement utilisées. Ce double processus fournit une dénégation plausible aux autres parties impliquées dans les différentes branches de dépenses que vous construisez quant à leur implication dans cet UTXO, et les protège également contre un voleur ou un attaquant qui les ciblerait de manière préventive en sachant qu’ils ont un certain degré de contrôle sur les UTXO de leur cible.
D’un point de vue technique, Taproot a également été relativement bien conçu. Toute personne qui lit et qui est familière avec Segregated Witness à un niveau profond devrait être familière avec la version témoin.
Lorsque le témoin séparé a été mis en œuvre, il a créé la nouvelle section « témoin » d’une transaction dans laquelle les données de signature ont été déplacées. Les données du témoin avaient un indicateur de version afin de pouvoir être mises à niveau vers de nouvelles fonctionnalités sans avoir à utiliser des OP_CODEs non définis sur la couche de base pour les nouvelles fonctionnalités.
C’est en fait la façon dont Taproot/Schnorr ont été implémentés. Les transactions à témoin séparé utilisent la version zéro du témoin. Lorsque Taproot/Schnorr seront mis en service prochainement, ils utiliseront la nouvelle version 1 du témoin pour les distinguer des anciennes transactions Segregated Witness. De la même manière que SegWit a introduit des versions de témoins, Taproot introduit une « version tapleaf » pour les tapscripts utilisés dans les arbres MAST pour les UTXOs utilisant Taproot. Cela permet non seulement de mettre à niveau les scripts enfouis dans MAST sans utiliser de nouveaux OP_CODEs sur la couche de base, mais aussi sans devoir mettre à niveau les versions des témoins non plus ! Ainsi, Taproot a été conçu pour être aussi efficace que possible pour une mise à niveau future sans limiter d’autres mises à niveau non liées au protocole.
Taproot apportera de nombreux cas d’utilisation différents. Pour commencer, toutes les clauses non coopératives d’un canal Lightning, comme les clés de pénalité ou les horloges permettant de les utiliser, peuvent être enterrées sous un MAST avec Taproot. Personne ne saura jamais qu’elles existent, à moins qu’elles ne doivent être utilisées, ce qui obscurcit encore plus les UTXO qui sont en fait des canaux Lightning ou non.
Les schémas d’héritage sont un autre cas d’utilisation. Imaginez un arbre Taproot structuré de telle sorte qu’après six mois d’immobilisation de votre argent, toute votre famille puisse se réunir et dépenser l’UTXO comme bon lui semble. Puis, six mois plus tard, tout le monde moins une personne peut le dépenser (imaginez donc que vous ayez votre femme, deux enfants et vos parents comme détenteurs de clés, puis imaginez qu’après les six mois supplémentaires, votre femme, un enfant et vos parents puissent signer, ou que vos deux enfants et vos parents puissent signer sans votre femme, et ainsi de suite).
Puis, six mois après, tout le monde moins deux personnes peut le dépenser. Finalement, cela pourrait se résumer à une seule personne avec l’aide d’un avocat (pour s’assurer qu’il n’y a pas de manigances) qui pourrait dépenser l’UTXO.
Ou, et si vous utilisez multisig pour sécuriser votre stockage à froid, mais que vous n’avez qu’un seul endroit que vous considérez comme sûr et prévisible à long terme ? Vous pourriez créer un MAST où éventuellement, après quelques années, la clé à cet endroit sécurisé peut dépenser ces pièces seule, juste au cas où d’autres clés seraient perdues ou détruites, mais sans mettre vos pièces immédiatement en danger de vol dans le présent si cette seule clé était compromise.
Il s’agit d’une mise à niveau étonnante et complète de Bitcoin, qui était sans doute en préparation depuis presque la naissance de Bitcoin lui-même, et pas seulement au cours des dernières années où les détails de la mise en œuvre ont été élaborés et mis en œuvre.
Il s’agit vraiment d’une victoire à bien des égards pour l’évolutivité et l’utilité du protocole Bitcoin, qu’il est difficile de faire comprendre en raison de la subtilité et du caractère peu sexy de certains d’entre eux. Mais cela n’enlève rien à cette victoire. Alors, que chacun s’attache et se prépare à jouer avec les nouveaux jouets que nous devrons bientôt utiliser, car Taproot arrive !
Ceci est un article invité par Shinobi. Les opinions exprimées sont entièrement les siennes et ne reflètent pas nécessairement celles de BTC Inc. ou de la Commission européenne. Bitcoin Magazine.
