Tapscript et arbres de scripts (MAST)

Curiosité

1. Pourquoi des dépenses relevant d’une seule clause d’un contrat devraient-elles révéler l’ensemble du contrat ?
2. Qu’est-ce qui rend une dépense coopérative indiscernable d’une simple signature ?
3. Comment une seule clé peut-elle s’engager envers toute une bibliothèque de conditions de dépense cachées ?

Explorer

1. Les arbres syntaxiques abstraits merkelisés (MAST) ont été décrits pour la première fois par Russell O’Connor en 2013, puis développés dans des propositions en 2016 et 2017. Le concept consistait à placer des conditions de dépense alternatives dans un arbre de Merkle, afin que la partie qui dépense ne révèle que la branche précise qu’elle utilise. Alors que le terme « arbre syntaxique abstrait » désignait des structures de compilateur où chaque condition crée un nouveau nœud, l’implémentation de Bitcoin a évolué différemment. Anthony Towns a ensuite forgé le rétroacronyme « Merklized Alternative Script Tree » pour décrire la structure effectivement adoptée : un ensemble de scripts complets et indépendants, dont un seul est sélectionné au moment de la dépense.
2. Taproot a intégré cette structure arborescente dans les règles de consensus via BIP341. Chaque feuille de l’arbre de Merkle contient un script, et la racine de cet arbre entre dans le calcul de la clé de sortie finale. Lorsque des fonds sont dépensés par le « chemin de script » (script path), la partie qui dépense révèle le script de la feuille concernée, ses entrées et la preuve de Merkle, c’est-à-dire les hachages des nœuds frères à chaque niveau. Les branches inutilisées restent cachées on-chain, ce qui préserve la confidentialité de montages complexes comme les multisig ou les timelocks, qui devaient auparavant être encapsulés dans des structures P2SH.
3. Tapscript (BIP342) est le dialecte propre à ces scripts de feuille ; il s’écarte du Bitcoin Script historique sur plusieurs points essentiels. OP_CHECKMULTISIG est désactivé dans tapscript. Son remplaçant, OP_CHECKSIGADD, vérifie une signature par rapport à une clé et ajoute 1 à un compteur courant ; une signature vide n’ajoute rien, tandis qu’une signature non vide invalide fait échouer tout le script ; un script enchaîne un OP_CHECKSIGADD par clé et compare le compteur au seuil. Chaque signature est associée à une clé connue : il n’y a donc pas d’appariement par tâtonnement, et les signatures peuvent être vérifiées par lots.
4. Tapscript réserve également de la place pour des mises à niveau grâce aux opcodes OP_SUCCESS : aujourd’hui, tout script qui en contient un est validé inconditionnellement, si bien que personne ne les utilise, et un futur soft fork pourra leur donner des significations restrictives sans invalider quoi que ce soit en usage. L’ancienne limite de 10 000 octets sur la taille des scripts est supprimée dans tapscript ; la taille d’un script n’est plus bornée que par le poids du bloc et les limites de politique. En outre, un budget d’opérations de signature proportionnel à la taille du témoin empêche les attaques par déni de service fondées sur une vérification excessive de signatures.
5. Prenons un exemple concret : un utilisateur détient des fonds dans un chemin de clé 2-of-2 pour ses dépenses courantes, où les deux parties signent de manière coopérative afin de ne révéler qu’une signature Schnorr standard. Toutefois, l’arbre de scripts contient une feuille cachée qui permet à une seule clé de dépenser seule après un timelock d’un an. Si le partenaire coopératif ne répond plus, l’utilisateur peut activer cette branche de récupération. La preuve de Merkle ne révèle que ce script de timelock précis, et les autres branches éventuelles, comme une récupération sociale ou des hashlocks, restent entièrement confidentielles.
6. Pour vérifier ces mécanismes, ouvrez un explorateur de blocs et repérez une transaction Taproot dépensée par le chemin de script. Examinez le témoin : les entrées du script, le script de feuille lui-même et un bloc de contrôle dont le premier octet combine la version de feuille (0xc0 pour tapscript) et un bit de parité, suivi de la clé interne et d’un hachage de 32 octets par niveau de l’arbre. Comparez-la à une dépense par le chemin de clé depuis le même type d’adresse ; cette dernière ne révèle qu’une signature de 64 ou 65 octets et aucune donnée de script, ce qui montre comment les contrats complexes restent invisibles lorsqu’ils ne sont pas utilisés.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• BIP341: Taproot: SegWit version 1 spending rules
• BIP342: Validation of Taproot Scripts
• Bitcoin Optech, 'MAST' and 'Tapscript' topics
• Anthony Towns, 'Merklized Alternative Script Trees' proposal discussions