Taproot et les signatures Schnorr

Curiosité

1. Pourquoi un accord complexe multipartite ressemble-t-il exactement à un paiement individuel simple sur la blockchain ?
2. Comment plusieurs clés privées peuvent-elles se combiner en une seule clé publique sans jamais révéler leur existence aux observateurs ?
3. Quelle propriété mathématique permet à une signature de dix personnes d’être indiscernable d’une signature d’une seule personne ?

Explorer

1. Avant Taproot, une condition de dépense complexe était révélée dans son intégralité chaque fois que les pièces étaient dépensées (et, pour les scripts nus, figurait dans la sortie elle-même) : une dépense multisig montrait la clé de chaque participant, un timelock sa durée, un hashlock sa structure. Cette transparence publique créait des risques pour la vie privée des utilisateurs avancés et encombrait l’espace des blocs de données redondantes. Le réseau traitait tous les scripts comme des livres ouverts, obligeant les montages complexes à diffuser toute leur logique à chaque nœud et à chaque observateur.
2. Taproot (BIP341) modifie le modèle d’engagement. Une sortie pointe désormais vers une seule clé publique Q de 32 octets, calculée comme P + t·G. Ici, P est une clé interne contrôlée par la partie qui dépense en priorité, tandis que t est un engagement envers la racine de Merkle d’un arbre facultatif de scripts alternatifs. On-chain, la sortie ressemble à n’importe quel paiement à clé unique et masque toute la complexité qui peut se trouver derrière.
3. Les signatures Schnorr (BIP340) sous-tendent cette efficacité. Contrairement à ECDSA, qui utilise un encodage DER de longueur variable de 71–72 octets en moyenne, Schnorr produit une signature de taille fixe de 64 octets (65 avec un type de hachage de signature autre que celui par défaut). Cette taille fixe simplifie l’analyse et réduit le poids des transactions. La linéarité du schéma de Schnorr permet aussi l’agrégation de clés : avec un protocole comme MuSig2, plusieurs clés publiques peuvent être combinées en une seule clé agrégée, ce qui permet à des groupes de signer comme une seule entité sans révéler les participants individuels.
4. La dépense peut se faire par deux chemins distincts. Dans le chemin de clé (key path), toutes les parties coopèrent et signent avec leur clé agrégée ; la transaction obtenue est indiscernable de n’importe quel paiement ordinaire à clé unique. Aucun script n’est révélé et aucune donnée supplémentaire n’est jointe. Cela préserve la confidentialité lors des fermetures coopératives de canaux Lightning ou des dépenses de portefeuilles multisig, et garantit que les montages financiers complexes ne laissent fuiter aucune métadonnée dans le registre public de la blockchain.
5. Si la coopération échoue, le chemin de script (script path) entre en jeu. La partie qui dépense révèle une feuille précise de l’arbre de Merkle, accompagnée d’une preuve de son appartenance à l’arbre. Les branches inutilisées restent cachées, ce qui préserve la confidentialité des conditions alternatives. Ce mécanisme, appelé MAST (Merkelized Abstract Syntax Trees, arbres syntaxiques abstraits merkelisés), permet à diverses règles de dépense, comme des retraits différés ou des clés d’urgence, de coexister dans une seule sortie sans être exposées avant que cela ne soit strictement nécessaire.
6. L’impact pratique est considérable. Les adresses Taproot commencent par « bc1p ». MuSig2 (BIP327) standardise l’agrégation de clés, ce qui permet un multisig interopérable entre portefeuilles de différents fournisseurs. Des schémas à seuil comme FROST sont en cours de développement dans le même but. En novembre 2021, au bloc 709 632, le réseau a adopté cette structure, rendant les scripts complexes plus compacts, moins coûteux et confidentiels par défaut lorsqu’ils sont utilisés de manière coopérative.

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
• BIP340: Schnorr Signatures for secp256k1
• BIP327: MuSig2 for BIP340-compatible Multi-Signatures
• Bitcoin Optech, 'Taproot' topic guide