Taproot : des smart contracts confidentiels pour Bitcoin

Bitcoin évolue lentement mais sûrement. Dans un précédent article, je vous parlais des signatures de Schnorr, la prochaine évolution majeure de Bitcoin. Aujourd'hui, je vais m'intéresser à Taproot, dont il a été confirmé qu'il serait intégré au protocole en même temps que ce nouveau schéma de signature.

Taproot est un procédé de programmation de contrats autonomes qui a la particularité de préserver la confidentialité de ses participants. Taproot repose pour cela sur des méthodes cryptographiques spécifiques que sont les arbres de Merkle (« MAST ») et l'agrégation des clés permise par les signatures de Schnorr (MuSig).

L'idée de Taproot a été présentée par Gregory Maxwell en janvier 2018 et elle a depuis été approfondie par les développeurs de Bitcoin Core. Le 6 mai dernier, Pieter Wuille a publié deux BIP concernant cette amélioration : l'un sur Taproot lui-même, et l'autre sur Tapscript qui définit la sémantique des scripts utilisés par Taproot. Taproot sera prochainement implémenté dans Bitcoin avec les signatures de Schnorr, vraisemblablement en 2020.

Les contrats autonomes dans Bitcoin (P2SH)

Les gens ne le savent pas forcément, mais Bitcoin est un système de monnaie programmable. Bien qu'il n'égale pas Ethereum en terme de flexibilité, Bitcoin n'en est pas moins capable de gérer des contrats autonomes (smart contracts) de façon efficace. Les canaux de paiement, qui sont les éléments de base du réseau Lightning, en constituent un exemple parlant.

La programmation dans Bitcoin est généralement réalisée par le biais d'adresses P2SH (Pay-to-Script-Hash) ou P2WSH (Pay-to-Witness-Script-Hash). Les bitcoins envoyés à une adresse de ce type sont verrouillés dans un contrat (aussi appelé script). Ce contrat possède un certain nombre de conditions de dépense (spending conditions) : celles-ci peuvent consister à demander une signature simple, inclure un schéma de multi-signature, ou encore faire intervenir un verrou temporel.

À titre d'illustration, voici à quoi peut ressembler un contrat sur Bitcoin :

IF
  2 <clé publique d'Alice> <clé publique de Bob> 2 CHECKMULTISIG
ELSE
  IF
    <temps de verrouillage : 30 jours> CHECKSEQUENCEVERIFY DROP
    <clé publique de Carole> CHECKSIG
  ELSE
    <verrouillage jusqu'en 2050> CHECKLOCKTIMEVERIFY DROP
    <clé publique de Damien> CHECKSIG
  ENDIF
ENDIF

Ce contrat possède 3 conditions de dépense pour des pièces envoyées à l'adresse qui correspond :

• Ou bien Alice et Bob fournissent leurs signatures ;
• Ou bien Carole signe après que 30 jours se soient écoulés ;
• Ou bien Damien signe après 2050.

Grâce au schéma P2SH (ou P2WSH), ces conditions ne sont pas révélées immédiatement. Cependant, au moment de la dépense des bitcoins, l'ensemble des conditions du contrat doivent être écrites à l'intérieur de la transaction, ce qui affecte la confidentialité des participants, ainsi que la scalabilité du protocole.

Les arbres syntaxiques abstraits merkélisés (MAST)

Les arbres syntaxiques abstraits merkélisés ou MAST (pour Merklized Abstract Syntax Trees) sont des arbres de hachage (dits « de Merkle ») permettant de structurer les contrats sur Bitcoin. Le concept d'arbre de Merkle n'est pas nouveau : il est d'ailleurs déjà utilisé au sein de Bitcoin pour retrouver les transactions dans les blocs. Le principal avantage des MAST est qu'ils cachent les conditions non-exécutées des contrats.

Reprenons notre exemple de contrat à 3 conditions de dépense. On considère chacun des scripts séparément et on les hache. Le script d'Alice et Bob donnera l'empreinte H_AB, celui de Carole H_C, etc. Les empreintes ensuite concaténées deux à deux et hachées une nouvelle fois. L'opération est répétée jusqu'à ce qu'il ne reste plus qu'une seule empreinte : la racine de Merkle de l'arbre (qui est ici H_ABCD).

Arbre de Merkle correspondant au contrat. Conformément à l'usage, l'arbre est représenté à l'envers (la racine est en haut et les feuilles en bas).

Cette structure autorise les membres du réseau à traiter un contrat autonome dans lequel ils n'ont pas à connaître les clauses de tous les participants. Il leur suffira pour cela de conserver la racine de l'arbre. Au moment de la dépense, les nœuds vérifieront que la structure et le contenu de l'arbre est bien valide, et seules les conditions exécutées seront révélées.

Par exemple, si Carole veut récupérer les fonds au bout de 30 jours, elle devra transmettre le script de règlement (verrouillage) correspondant à son cas :

<temps de verrouillage : 30 jours> CHECKSEQUENCEVERIFY DROP
<clé publique de Carole> CHECKSIG

Ainsi que le script de déverrouillage constitué de sa signature :

<signature de Carole>

Carole aura également à donner le chemin de Merkle de sa condition constitué des empreintes H_D et H_AB, ce qui permettra aux nœuds du réseau de vérifier que tout est en ordre en recalculant les autres empreintes.

Ces arbres de Merkle permettent donc d'atteindre un certain niveau de confidentialité. Toutefois, avec Taproot on peut faire mieux : il est en effet possible de faire en sorte que la structure de MAST ne soit pas révélée du tout au moment de la transaction.

Taproot, la racine pivot

C'est là qu'on utilise les avantages apportés par les signatures de Schnorr. En effet, bien qu'ECDSA puisse faire l'affaire dans une certaine mesure, le schéma de Schnorr est lui bien plus efficace. Grâce à ses propriétés de non-malléabilité et de linéarité, il permet d'effectuer des agrégations de clés et donc de réaliser des opérations de multi-signature de manière confidentielle. La méthode utilisée pour faire cela est appelée MuSig.

L'idée de Taproot, c'est d'ajouter une condition de fermeture coopérative à l'arbre de Merkle du contrat requérant la signature de tous les participants. Son nom (« racine pivot ») est provient du fait que cette condition est ajoutée un cran plus bas que la racine de l'arbre. Une analogie pertinente est celle du tribunal : on signe des contrats avec d'autres personnes, mais on ne passe devant la justice qu'en cas de litige. Ainsi, pour approuver une transaction, tous les participants pourront se contenter de la signer, et celle-ci ne sera pas discernable d'une transaction classique ! Cela aura pour effet de préserver les informations personnelles des participants et de réduire leurs frais.

Comment cela fonctionne ? D'abord, les participants agrègent leurs clés grâce à MuSig et obtiennent une clé publique « seuil » interne. Cette clé publique est ensuite modifiée légèrement (« tweaked ») pour inclure les données du contrat, qui, on le rappelle, est structuré sous la forme d'un arbre de Merkle. La clé obtenue est la clé publique externe visible aux yeux du réseau.

En cas de fermeture coopérative, chacun des participants n'aura ensuite qu'à modifier légèrement sa clé privée avec le contrat et la clé publique interne pour signer la transaction. Enfin, les signatures seront agrégées en une signature « seuil » qui correspondra à la clé publique externe et les fonds pourront être dépensés¹.

En cas de litige, un participant pourra dépenser les bitcoins en fournissant la structure du contrat (l'arbre de Merkle), la clé publique interne ainsi que les données nécessaires pour satisfaire sa partie du contrat. Il faut donc que les participants gardent en mémoire les données qui ont servi à construire ce schéma.

Comment Taproot sera implémenté et qu'est-ce qu'il apportera ?

Taproot verra le jour sur Bitcoin en même temps que le schéma de signature de Schnorr. Cette mise à niveau sera implémentée sous la forme d'un soft fork utilisant la version 1 de SegWit (nous sommes pour l'instant cantonnés à la version 0). Des adresses spécifiques seront utilisées pour l'occasion, même s'il s'agira toujours d'adresses SegWit natives commençant par bc1. Cela permettra une transition progressive vers cette innovation et évitera de mettre tous les fonds du réseau en jeu dès le premier jour.

Dans les avantages apportés par Taproot, il y a bien évidemment la confidentialité des contrats autonomes : le procédé permet en effet de cacher le fait même qu'un contrat a existé. Taproot offrira aussi une plus grande flexibilité dans ces contrats, notamment grâce à Tapscript. Enfin, il améliorera grandement la scalabilité du protocole, en évitant à toutes les conditions contractuelles d'être traitées par le réseau et conservées sur la chaîne.

Notes

1. ↑ Notons C le contrat, G le point générateur de secp256k1, h la fonction de hachage utilisée dans Taproot, || la concaténation. Si P désigne la clé publique interne issue de l'agrégation des clés des participants, alors la clé publique externe Q est calculée par la formule :

Q = P + h(P || C) G

Chacun des participant modifiera légèrement sa clé privée k_i par :

ti = ki + h(P || C)

Si chaque participant signe la transaction avec sa clé privée t_i, la signature obtenue par agrégation correspondra à la clé publique externe Q.

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