Taproot arrive: ce qu'il est et comment il profitera au Bitcoin

Les utilisateurs de Bitcoin pourraient, bientôt, être en mesure de bénéficier d'une astuce appelée Taproot. D'abord proposée par le contributeur de Bitcoin Core et ancien CTO de Blockstream Gregory Maxwell, Taproot élargirait la flexibilité des contrats intelligents de Bitcoin, tout en offrant plus de confidentialité.

Bien qu'il s'agisse d'une grande entreprise, ce n'est pas seulement une théorie. Plusieurs des contributeurs les plus prolifiques du Bitcoin Core , y compris Pieter Wuille, Anthony Towns, Johnson Lau, Jonas Nick, Andrew Poelstra, Tim Ruffing, Rusty Russell et, en effet, Gregory Maxwell travaillent sur une proposition de signature Schnorr qui inclurait Taproot, le tout dans une mise à niveau de protocole.

Voici ce qu'est Taproot et comment il fonctionne.

P2SH

Tous les bitcoins sont essentiellement "verrouillés" dans des scripts: quelques lignes de code intégrées dans une transaction incluse dans la blockchain, qui définissent comment les pièces peuvent être dépensées dans la prochaine transaction. Les conditions de dépenses impliquent généralement la fourniture d'une signature pour prouver la propriété des pièces.

Des conditions différentes peuvent être mélangées et jumelées, pour créer des types complexes de contrats intelligents. Un exemple de tel contrat pourrait être que les pièces peuvent être dépensées si Alice et Bob signent tous les deux, ou si Alice signe seule après une semaine, ou si Bob signe seul tout en fournissant un numéro secret.

Depuis 2012, les scripts (les conditions) ne sont souvent pas visibles au public au début; seul le nouveau propriétaire des pièces sait comment ils peuvent être dépensés. Cela se fait avec une astuce appelée P2SH (pay to script hash), où initialement seul un hachage du script est inclus dans la blockchain. Ce nombre apparemment aléatoire déchiffré détient les pièces. Lorsque le propriétaire dépense les pièces, il révèle tout le script ainsi que la solution au script en même temps.

Néanmoins, lorsque les pièces sont dépensées, il est actuellement nécessaire de révéler toutes les conditions possibles qui auraient pu être remplies, y compris les conditions qui n'ont pas été remplies. Cela a deux inconvénients principaux. Premièrement, c'est lourd de données, surtout s'il y a beaucoup de conditions. Deuxièmement, c'est mauvais pour la vie privée. Tout le monde apprend toutes les différentes façons dont les fonds auraient pu être dépensés, ce qui peut, par exemple, révéler le type de portefeuille utilisé et peut-être même plus.

Mast

MAST (Merkelized Abstract Syntax Tree) est une solution proposée qui utilise des arbres Merkle (une structure de données compacte et vieille de plusieurs décennies inventée par le cryptographe Ralph Merkle) pour contourner ces deux inconvénients.

L'avantage unique est que si l'une des données de l'arbre Merkle est révélée, la racine de Merkle et certaines données supplémentaires (appelées chemin de Merkle) peuvent être utilisées pour vérifier que ces données spécifiques ont été incluses dans l'arbre Merkle.

Avec MAST, cela signifie que seule la condition qui est remplie doit être révélée. Si, dans l'exemple initial ci-dessus, Alice seule dépense les fonds après une semaine, elle révèle simplement cette condition (et le chemin de Merkle). Personne n'apprend que l'argent aurait également pu être dépensé par Alice et Bob ensemble, ou par Bob seul s'il avait ajouté un numéro secret. Cela rend MAST plus efficace que les contrats intelligents P2SH complexes et ajoute la confidentialité au démarrage.

Pourtant, avec Schnorr, Taproot peut faire encore mieux: une transaction peut cacher qu'une structure MAST existait.

Je suis Schnorr.

Le schéma de signature Schnorr est depuis longtemps sur la liste de souhaits de nombreux développeurs Bitcoin et est actuellement en développement pour être déployé comme une mise à niveau du protocole soft fork.

Comme son avantage le plus connu dans le contexte du Bitcoin, le mathématique linéaire de Schnorr permet l'agrégation de signatures: plusieurs signatures dans la même transaction peuvent être combinées en une seule. Une astuce similaire pourrait être appliquée aux transactions multisig.

Par exemple, il est possible d'utiliser des données pour modifier à la fois une clé privée et une clé publique. À titre d'exemple simplifié, une clé privée et sa clé publique correspondante pourraient être modifiées en multipliant les deux par deux. La clé privée x 2 et la clé publique x 2 correspondraient toujours, et la clé privée x 2 pourrait toujours signer des messages qui pourraient être vérifiés avec la clé publique x 2.

C'est ce qui permet à Taproot.

Résine

Dans l'exemple précédent, si Bob sait qu'Alice peut, par elle-même, réclamer tous les fonds la semaine prochaine, il pourrait tout aussi bien coopérer avec elle maintenant pour signer ensemble. (Dans de nombreuses configurations de contrats intelligents typiques, il serait même pénalisé s'il ne le fait pas. La complexité sert vraiment à garder tout le monde honnête.)

Taproot ressemble au MAST et inclut toujours une condition où tous les participants peuvent coopérer pour dépenser les fonds: la "close coopérative".

En utilisant les signatures Schnorr, c'est là que ça devient intéressant.

Tout d'abord, la clôture coopérative utiliserait le truc de seuil de Schnorr pour le faire ressembler à une transaction régulière, d'une personne à une autre. Ainsi, les clés publiques de tous les participants sont ajoutées, ce qui donne la clé publique de seuil. Correspondant à cette clé publique de seuil, la combinaison de toutes les signatures des participants leur permet de dépenser les fonds.

Jusqu'à présent, c'est bien, mais dépenser les fonds comme si c'était une transaction normale est la seule chose qu'ils peuvent faire pas encore de structures de type MAST.

Toutes les façons alternatives de dépenser les fonds les résultats non coopératifs sont cette fois combinés dans un script différent. Ce script est ensuite haché et utilisé pour modifier la clé publique de seuil. Plutôt que clé publique x 2, comme utilisé dans l'exemple précédent, cela donne lieu à un clé publique de seuil x script.

Maintenant, si l'argent est dépensé de manière coopérative, tous les participants combinent leurs signatures dans la signature de seuil et la peaufinent avec le script. La signature de seuil x script qui en résulte leur permet de dépenser les fonds. Pourtant, et ce qui est important, pour le monde extérieur, tout cela ressemblerait toujours à une clé publique régulière et une signature régulière une transaction régulière.

Ce n'est que si une clôture coopérative s'avère impossible que la clé publique de seuil peut être montrée pour ce qu'elle est réellement: modifiée.

Dans ce cas, à la fois la clé publique de seuil d'origine et le script sont révélés. Cela prouve que la clé publique de seuil x script a été modifiée avec ce script spécifique. Ainsi, comme le hachage dans P2SH, le tweak prouve au monde que les fonds devraient être dépensables si les conditions alternatives, telles que spécifiées dans ce script, sont remplies. (Et, comme avec P2SH, ces conditions sont bien sûr immédiatement remplies pour dépenser les fonds.)

Alternativement, au lieu de modifier la clé publique de seuil avec un script, la clé publique de seuil peut être modifiée avec une racine Merkle d'un arbre Merkle qui inclut toutes les différentes conditions dans lesquelles les fonds peuvent être dépensés: une structure MAST.

En tant que tel, Taproot offre tous les avantages de MAST, alors que dans des circonstances normales, personne ne saura jamais qu'une transaction régulière cachait un contrat intelligent aussi complexe comme une solution de secours.

Pour plus de détails, lisez la proposition originale de Taproot de Gregory Maxwell ou regardez cette présentation de Pieter Wuille.