↓ Aller au contenu
Ixonae on Security
  1. Articles/

Soft-Fork Taproot : qu'apporte-t-il à Bitcoin ?

·6 mins
Ixonae
Cryptomonnaies
Ixonae
Auteur
Ixonae
Sommaire

Avertissement : Cet article a été traduit de l’anglais par un LLM. La précision n’est pas garantie. Vous pouvez lire l’article original en anglais.

Le soft fork Taproot a finalement été activé le dimanche 14 avec le bloc 709 634. Il s’agit de la première mise à jour majeure de Bitcoin depuis SegWit en 2017. Son implémentation a été décidée en juin de cette année (au bloc 687 284) lorsque 90% des blocs minés ont signalé leur soutien à la mise à jour sur une période de deux semaines (pour être plus précis, l’exigence était d’avoir 1 815 des 2 016 blocs soutenant la mise à jour).

Taproot comprend trois propositions d’amélioration de Bitcoin (BIP340, BIP341 et BIP342) incluant les signatures Schnorr, MAST et Tapscript. Dans cet article, nous les passerons tous en revue et verrons comment ils fonctionnent et ce qu’ils apportent à Bitcoin. Notez que les changements permettent la rétrocompatibilité (ce qui signifie que vous pourrez toujours utiliser les anciens types d’adresses).

Signatures Schnorr
#

Jusqu’à présent, Bitcoin utilisait des signatures ECDSA (courbes secp256k1) avec des hachages SHA256 pour authentifier les transactions. Le BIP 340 introduit une nouvelle façon de faire des signatures en utilisant Schnorr. Le nouveau mécanisme utilise aussi la cryptographie à courbe elliptique, mais son principal avantage est le support natif du multisig.

Dans la configuration actuelle, une transaction provenant d’une adresse multisig aura plusieurs signatures attachées. Cependant, puisque Schnorr est linéaire, il permet d’agréger plusieurs signatures en une seule (« agrégation de clés »). Cela offre les avantages suivants :

  • Les transactions multisig auront toujours une seule signature de la même taille, quel que soit le nombre de participants, ce qui offre des améliorations de performance (une seule signature à vérifier au lieu de plusieurs, et Schnorr est plus rapide qu’ECDSA). Cela offre aussi un gain de capacité réseau puisque leur taille sera plus petite.
  • Avec Schnorr, il n’est pas possible de savoir si une adresse est multisig ou non, et combien de participants y ont pris part, tant que tout le monde signe les transactions

Voyons plus en détail comment les choses se dérouleraient en conditions réelles avec une adresse P2SH 3/3 historique. La partie gauche du schéma montre le processus de création de l’adresse et la partie droite montre comment dépenser les fonds envoyés à cette adresse.

L’ancienne façon de créer une adresse multisig 3/3 et de dépenser les fonds

Le schéma précédent ne devrait pas être une surprise si vous êtes familier avec Bitcoin ; nous observons que lorsque les fonds sont dépensés, il est possible de voir que le script nécessitait les signatures A, B et C (les trois clés attendues seraient révélées même si l’adresse était un multisig 2/3).

Maintenant, regardons comment les choses fonctionneraient avec les adresses Taproot. Comme précédemment, la partie gauche du schéma montre la création de l’adresse, et la partie droite comment dépenser les fonds avec.

Création d’une adresse multisig 3/3 et dépense des fonds

Dans ce cas, la seule chose qui sera présente sur la blockchain est la signature agrégée correspondant à la clé publique générée lors de la première étape. Par conséquent, il ne sera pas possible de savoir en regardant la transaction que les fonds étaient stockés dans une adresse multisig. Dans le cas où l’adresse permettrait 2/3 signatures, les choses seraient aussi légèrement différentes et nous en discuterons plus en détail plus tard.

Branche de Merkle
#

Le BIP 341 introduit MAST (Merkelized Abstract Syntax Tree) comme moyen de faire des transactions de paiement par script. Auparavant, le script complet devait être partagé pour pouvoir dépenser les fonds envoyés à une adresse P2SH. Avec la nouvelle approche, seule la partie du script qui est effectivement utilisée est rendue publique. Cela a deux avantages : cela nécessite moins d’espace sur la blockchain et cela améliore la confidentialité des entités participant aux transactions. Regardons le schéma suivant comme exemple. Il montre un script impliquant quatre clés publiques (1, 2, 3 et 4) qui permet d’envoyer de l’argent soit avec deux signatures des clés 1, 2 ou 3, soit avec une seule signature de la clé 4 si le bloc actuel est supérieur à x.

Exemple de script MAST

Supposons que nous voulions envoyer des fonds en utilisant les clés 1 et 2. Dans ce cas, nous signerons la transaction avec les clés privées 1 et 2, puis nous révélerons le script 1 et les éléments en vert. Ce faisant, les conditions pour le script 1 sont remplies, et le hash racine (qui a été utilisé lors de la création de l’adresse) peut être recalculé, prouvant ainsi que le script 1 est autorisé à être utilisé pour dépenser les fonds.

P2TR (Pay-To-Taproot)
#

Afin de supporter les changements précédents, le BIP341 introduit les règles de dépense SegWit version 1 (le SegWit de 2017 était la version 0) ainsi que le nouveau type d’adresse Pay-To-Taproot (P2TR). Ces adresses commenceront par bc1q au lieu de bc1q.

L’un des avantages de P2TR est qu’il peut être utilisé pour payer à un script ou à une clé publique, et il ne sera pas possible de dire lequel des deux est une adresse tant que les fonds n’ont pas été dépensés. En fait, même après cela, il peut ne pas être possible de savoir s’il y avait un script car il existe une option qui permet à toutes les parties impliquées dans un smart contract de signer une transaction plutôt que de suivre les règles du script.

Tapscript
#

Tapscript - activé par le BIP342 - est la dernière partie de la mise à jour Taproot et inclut des améliorations de la structure des scripts pour s’adapter aux autres changements. Entre autres choses, le BIP342 fait ce qui suit :

  • Modifier OP_CHECKSIG et OP_CHECKSIGVERIFY pour être utilisables avec les signatures Schnorr
  • OP_CHECKMULTISIG et OP_CHECKMULTISIGVERIFY sont désactivés et remplacés par OP_CHECKSIGADD
  • La taille maximale de script de 10 000 octets ne s’applique plus, et la taille est simplement limitée par la limite de poids du bloc

De plus, pour faciliter les futures améliorations des scripts, Tapscript inclut de nouveaux opcodes (instructions de transaction) qui peuvent être utilisés pour ajouter des fonctionnalités. Les codes sont numérotés 80, 98, 126-129, 131-134, 137-138, 141-142, 149-153, 187-254, et si l’un d’entre eux est rencontré pour le moment, la validation réussira et ignorera les autres règles. Les opcodes sont nommés OP_SUCCESSx (par exemple, OP_SUCCESS80, OP_SUCCESS98, …, OP_SUCCESS254)

Support P2TR
#

Bitcoin.it a une liste des principaux portefeuilles et services Bitcoin et les types d’adresses vers lesquels ils peuvent recevoir des fonds. Jusqu’à présent, il semble que la plupart d’entre eux n’aient pas partagé de plan daté pour implémenter les adresses P2TR. Notamment, Trezor prévoyait de l’implémenter d’ici décembre de cette année.

Sources
#

Crédits
#