Taproot arrive sur Bitcoin : comment ça marche, son histoire et ses implications

Les signatures Taproot et Schnorr sont mises en ligne sur Bitcoin au bloc 709,632 XNUMX. Il s’agira d’une réalisation fondamentale considérable sur laquelle nous pourrons continuer à nous appuyer à l’avenir. Cela fait quatre ans que Segregated Witness a été mis en ligne sur le réseau, notre dernière mise à jour majeure du protocole. C’est aussi long qu’un cycle de réduction de moitié !

Pensez-y. Quatre ans entre la mise en ligne de SegWit et la mise en ligne 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 la racine pivotante

Certains qui sont ici depuis un certain temps pourraient trouver cela ironique, mais la première mention des signatures Schnorr à ma connaissance provenait en fait de l'ancien développeur de Bitcoin Core devenu constructeur de blockchain d'entreprise, Mike Hearn. En 2012, il soulevé l'idée d'une nouvelle courbe cryptographique par rapport à la vérification par lots des signatures pour rendre la validation des nœuds moins coûteuse en calcul. En fin de compte, le schéma qu'il proposait dépendait des signatures de Schnorr.

Adam Back parlait de naïveté Schémas pour créer des adresses multisig qui ressemblaient à des adresses singlesig en 2014, en utilisant les signatures Schnorr. Même Gavin Andresen inclus Schnorr au lieu d'ECDSA sur sa liste de souhaits de modifications qu’il apporterait à 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 souhaitaient les 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 système de signature de Schnorr était breveté et qu’il existait un énorme besoin d’un système de signature cryptographique open source non grevé de brevets.

Schnorr est beaucoup plus efficace et facilement manipulable (des choses peuvent être ajoutées, soustraites, etc. des signatures, et si cela est fait correctement, peuvent toujours laisser aux utilisateurs des signatures valides quand ils devraient les 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.

Les arbres de syntaxe abstraite merkelisés (MAST), la moitié Taproot de cette prochaine mise à niveau Taproot, ont une histoire similaire de longue date. Je ne parviens pas à trouver la citation, mais je me souviens très clairement avoir vu cette phrase lancée par Peter Todd sur Bitcointalk.org vers 2013 ou 2014.

L'ouverture a 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 ainsi que 117) et développé la proposition originale de Lau.

MAST est resté assis dans les limbes l'année suivante jusqu'à ce que Greg Maxwell propose l'idée initiale de Taproot et publié à la liste de diffusion Bitcoin-dev. Son idée clé était que dans tout cas de contrat entre plusieurs participants auquel il pouvait penser, il existait un « résultat optimal » où le contrat pouvait être réglé par tout le monde signant simplement le résultat approprié au lieu d'appliquer le résultat avec des scripts et des transactions plus avancés. Il s'agit de l'affirmation fondamentale sur laquelle Taproot est basé, c'est-à-dire l'ajustement de l'arborescence MAST à une clé de niveau supérieur régulière qui peut être dépensée sans révéler si un arbre Merkle d'autres conditions de dépenses existe même.

La dernière petite partie de cette leçon d'histoire commence avec Pieter Wiulle annonçant projets de BIP pour Schnorr et Taproot en tandem avec la liste de diffusion du 6 mai 2019. En janvier 2020, cela a été officiellement finalisé en BIP 340, 341 et 342. À partir de ce moment, ce n'était qu'un tas de petits détails de raffinement au niveau de la mise en œuvre, une période de révision, puis la longue attente bataille sur les mécanismes d'activation. Cela nous amène à maintenant, juste avant l'activation.

L'importance des signatures Schnorr

Alors, quel est le problème avec les signatures Schnorr ? Eh bien, pour commencer, ils réduisent la taille des transactions. Une signature ECDSA a généralement une taille d'environ 72 octets pour une seule signature dans une transaction. Les signatures Schnorr arrivent à un maximum de 64 octets par signature. Cela représente une économie de taille d'environ 12 % par rapport à l'ECDSA pour chaque signature Schnorr. C'est à la fois un avantage direct pour la personne utilisant Schnorr qui paiera moins de frais qu'un utilisateur ECDSA, mais c'est aussi un avantage direct pour les personnes n'utilisant pas Schnorr en exigeant qu'un peu moins de données soient stockées dans la blockchain pour traiter et valider le Schnorr de quelqu'un d'autre. signatures.

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 une propriété intéressante que vous souhaitez dans 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 une grande partie de la raison pour laquelle la validation des blocs consomme beaucoup de puissance CPU. Les signatures de Schnorr peuvent être toutes regroupées et validées mathématiquement en une seule fois, un peu comme les écraser ensemble et faire une opération mathématique au lieu d'un tas d'opérations individuelles. Ainsi, plus il y a de signatures de Schnorr, plus les économies de calcul sont importantes. Il s'agit d'un énorme gain de mise à l'échelle pour le réseau.

Une autre amélioration massive 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 du passage, et une signature doit être fournie pour chaque clé impliquée dans le processus de dépense. Avec les propriétés mathématiques de Schnorr, la porte s'ouvre pour MuSig, une norme multisignature. Vous pouvez simplement ajouter des clés ensemble et vous retrouver avec une seule clé publique que les partages de clés privées de tout le monde peuvent signer pour utiliser de nouveaux protocoles de signature. Jonas Nick de Blockstream référencé MuSig2 à prendre deux minutes pour un million participants à une adresse multisig à signer. L'amélioration de la mise à l'échelle des scripts multisignatures ne peut être sous-estimée.

Cet énorme bond en avant pour les scripts multisignatures a également d’énormes implications sur le profil de confidentialité et le coût de nombreuses applications construites sur Bitcoin. Les canaux Lightning basés sur MuSig peuvent désormais se fondre dans l'ensemble de l'ensemble anonyme des UTXO Schnorr/Taproot sur la chaîne, car personne ne sera plus en mesure de distinguer le fait qu'il s'agit d'une sortie multisig deux sur deux.

Ils se fondront et ressembleront à un seul script de signature. La même chose vaut pour tout UTXO multisig en général. Cela aura de nombreuses 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 regardant la blockchain, donc cela, comme dans le cas de Lightning, les fera se fondre avec tout le reste. Une victoire clé concerne cependant l'économie : l'utilisation de la multisignature nécessite actuellement de fournir une signature distincte pour chaque clé impliquée dans la dépense finale d'un UTXO. Avec Schnorr/MuSig, les choses seront compressées en une seule signature pour la clé publique combinée unique, ce qui signifie que dépenser des UTXO multisig en utilisant MuSig deviendra beaucoup moins cher car il pousse moins de données vers la blockchain.

Une dernière chose intéressante que font les signatures Schnorr est de simplifier considérablement la mise en œuvre des signatures d'adaptateur. Pensez à une signature d'adaptateur qui est "chiffrée" par une valeur qui a été ajoutée ou soustraite d'une signature valide. Il n'est pas valide tant que vous n'inversez pas cette opération mathématique, ou que vous ne la « déchiffrez » avec la « clé » qui a été utilisée pour la manipuler. C'est possible avec ECDSA, mais comme les calculs sont non linéaires par rapport à Schnorr, c'est relativement compliqué et il y a beaucoup de problèmes de sécurité à prendre en compte lors de 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 seul (disons, le nombre 9,300,030 30 XNUMX) et d'en soustraire une valeur (disons XNUMX). Une fois que la partie détenant la signature de l'adaptateur apprend la valeur soustraite, elle peut simplement la rajouter et voila, ils ont à nouveau une signature valide.

Les implications de la racine pivotante

Comme discuté un peu ci-dessus, Taproot en réalité est essentiellement juste MAST, sauf qu'au lieu de fonctionner comme P2SH (où vous hachez le script, ou dans le cas de MAST, la racine Merkle du haut de l'arborescence de script), vous "modifiez" un Clé publique de Schnorr par la racine de l'arbre de Merkle.

L'ajustement fonctionne grâce aux propriétés linéaires de Schnorr - lorsque vous "ajustez" une clé publique avec une racine Merkle (ajoutez cette racine Merkle à la clé publique), vous pouvez simplement ajouter la racine Merkle à la clé privée d'origine et générer la clé de dépense pour la nouvelle clé publique modifiée. C'est-à-dire que vous ajoutez la même chose à la fois à la clé publique et à la clé privée, et qu'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 ne s'agit toujours que d'un arbre MAST, juste un arbre engagé de manière plus efficace et privée.

La possibilité de s'engager dans différents scripts de dépenses dans un arbre Merkle et de révéler uniquement le script utilisé constitue un énorme gain d'évolutivité en termes de complexité des contrats intelligents qu'il est possible de construire sur Bitcoin.

Tout comme la taille de bloc limite le nombre de transactions par bloc, il existe une limite de restriction de taille de transaction de 100 kilo-octets. La seule différence est qu'au lieu d'être une règle consensuelle, c'est une règle politique. Cela signifie qu'un mineur peut exploiter une transaction supérieure à 100 kilo-octets, mais par défaut, aucun nœud sur le réseau ne transmettra une transaction plus importante que cela au mineur en premier lieu.

Cela limite intrinsèquement la taille du script utilisé pour verrouiller un Bitcoin UTXO. Même avec P2SH, où l'UTXO est verrouillé sur un hachage du script qui n'est révélé que lorsque vous le dépensez, vous devez finalement révéler le script complet au moment de l'utilisation. 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 limite de taille de transaction, vous devez simplement vous assurer que chaque façon dont vous pouvez dépenser un UTXO Taproot respecte cette limitation.

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 régimes d'héritage où, après environ un an, vos enfants peuvent dépenser vos pièces, ou dans le cas où vous refusez de signer, votre femme et un avocat ont un moyen potentiel de récupérer des pièces. Rien de ces conditions de dépenses n'est révélé au public à moins qu'elles ne soient effectivement utilisées. Ce processus en deux volets fournit un déni plausible pour les autres parties impliquées dans différentes branches de dépenses que vous construisez quant à leur implication dans cet UTXO, ainsi que les protège d'un voleur ou d'un attaquant les ciblant de manière préventive en sachant qu'ils ont un certain degré de contrôle sur leur les UTXO de la cible.

Sur le plan technique, Taproot a également été relativement bien conçu. Toute personne lisant qui connaît le témoin séparé à un niveau approfondi devrait connaître la version du témoin.

Lorsque Segregated Witness 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 témoins avaient un indicateur de version afin qu'elles puissent être mises à niveau vers de nouvelles fonctionnalités sans avoir à utiliser des OP_CODEs non définis sur la couche de base pour de nouvelles fonctionnalités.

C'est en fait ainsi que Taproot/Schnorr ont été implémentés. Les transactions de témoin séparé utilisent la version zéro du témoin. Lorsque Taproot/Schnorr sera bientôt mis en ligne, ils utiliseront la nouvelle version témoin pour les distinguer des anciennes transactions de témoins séparés. De la même manière que SegWit a introduit les versions témoins, Taproot introduit la "version tapleaf" pour les tapscripts utilisés dans les arbres MAST pour les UTXO utilisant Taproot. Cela permet non seulement aux scripts enfouis dans MAST de se mettre à niveau sans utiliser de nouveaux OP_CODEs sur la couche de base, mais également sans avoir à mettre à niveau les versions 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 variés. Pour commencer, toutes les clauses non coopératives d'un canal Lightning, telles que les clés de pénalité ou les timelocks permettant de les utiliser, peuvent être enterrées sous un MAST avec Taproot. Personne ne saura jamais qu'ils existent à moins qu'ils n'aient besoin d'être utilisés, obscurcissant davantage quels UTXO sont en fait des canaux Lightning ou non.

Les schémas d'héritage sont un autre cas d'utilisation. Imaginez un arbre à racine pivotante structuré de manière à ce qu'après six mois de non-déplacement de votre argent, toute votre famille puisse se réunir et dépenser l'UTXO comme elle le souhaite. Puis, six mois plus tard, tout le monde moins une personne peut le dépenser (alors imaginez si vous aviez votre femme, vos 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 peuvent signer , ou vos deux enfants et vos parents peuvent signer sans votre femme, etc.).

Puis, six mois plus tard, 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'aucune manigance ne se produise) pouvant dépenser l'UTXO.

Ou, que se passe-t-il si vous utilisez multisig pour sécuriser votre entrepôt frigorifique, mais que vous n'avez qu'un seul endroit que vous considérez comme sûr et prévisible à long terme ? Vous pouvez créer un MAST où, après quelques années, la clé de cet emplacement 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 cela une clé a été compromise.

Il s’agit d’une mise à niveau étonnante et complète de Bitcoin qui est sans doute en préparation depuis presque la naissance de Bitcoin lui-même, et pas seulement depuis les dernières années au cours desquelles les détails de la mise en œuvre ont été élaborés et mis en œuvre.

C’est vraiment une victoire à bien des égards pour l’évolutivité et l’utilité du protocole Bitcoin qu’il est difficile de transmettre en raison de la subtilité et du « peu sexy » de certains d’entre eux. Mais cela n’enlève rien à la victoire. Alors, tout le monde s'attache et est prêt à jouer avec les nouveaux jouets que nous devrons bientôt utiliser, car Taproot arrive !

Ceci est un article invité de Shinobi. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou Magazine Bitcoin.

Source : https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer