Qu'est-ce qu'une mise à niveau de Taproot et pourquoi Bitcoin en avait-il besoin ?

Mécanismes d’activation de la racine pivotante

1. Taproot activé à la hauteur de bloc 709632 le 12 novembre 2021, à la suite d'un mécanisme de consensus de soft fork exigeant 90 % de signalisation des mineurs sur une période d'ajustement de difficulté de 3 024 blocs.

2. La mise à niveau a introduit les sorties témoins de la version 1, remplaçant les structures témoins de ségrégation de la version 0 précédente utilisées dans les transactions P2WPKH et P2WSH.

3. Contrairement aux versions précédentes, les sorties Taproot codent toutes les conditions de dépenses dans un arbre de syntaxe abstraite merkleisé (MAST), permettant une logique conditionnelle sans exposer les branches inutilisées sur la chaîne.

4. L'activation n'a pas modifié la politique monétaire de Bitcoin ni la limite de taille de bloc, mais a redéfini la façon dont la validation du script est exécutée lors de la vérification de la transaction.

5. Les nœuds exécutant Bitcoin Core v0.21.1 ou version ultérieure reconnaissent et appliquent automatiquement les règles Taproot, garantissant ainsi une compatibilité descendante avec les adresses et portefeuilles existants.

Améliorations de la confidentialité grâce aux signatures Schnorr

1. Les signatures Schnorr ont remplacé ECDSA pour les dépenses en chemin de clé, produisant des signatures déterministes de 64 octets qui ne peuvent pas être distinguées des chaînes d'octets aléatoires pour les observateurs externes.

2. L'agrégation de signatures permet à plusieurs signataires de combiner leurs signatures partielles en une seule signature, éliminant ainsi les modèles d'empreintes multi-signatures visibles dans les UTXO pré-Taproot.

3. L'ajustement de la clé publique via l'ajout de points basés sur le hachage garantit que même lorsque la même clé publique apparaît sur plusieurs sorties, sa représentation en chaîne diffère à chaque fois.

4. Les données témoins pour les dépenses par chemin de clé ne contiennent qu'une signature (pas de script, pas d'opcodes, pas d'opérations de pile), ce qui rend l'intention de transaction opaque pour les analystes de la blockchain.

5. Les dépenses du chemin de script révèlent uniquement la branche exécutée d'un MAST, masquant toutes les conditions alternatives et les clés publiques associées, sauf si elles sont explicitement déclenchées.

Gains d'efficacité des transactions

1. Une dépense de chemin de clé P2TR standard consomme 57,5 voctets, contre 68 voctets pour une transaction P2WPKH équivalente, ce qui réduit les frais d'environ 15 % dans des conditions de pool de mémoire typiques.

2. Les configurations multi-signatures en bénéficient de manière disproportionnée : une dépense MuSig2 de 3 sur 5 correspond à 104 voctets contre 289 voctets pour l'ancien P2WSH, ce qui réduit les coûts de plus de 64 %.

3. La latence de propagation des blocs a diminué en raison de charges utiles de témoin plus petites, améliorant ainsi la vitesse de synchronisation complète des nœuds et réduisant les taux d'orphelins pendant les périodes de débit élevé.

4. Le temps de validation par transaction a été réduit jusqu'à 2,5 fois car la vérification de la signature Schnorr évite les inversions modulaires coûteuses requises par ECDSA.

5. Les modèles d'estimation des frais ont dû être recalibrés après l'activation pour tenir compte des contributions variables du poids des témoins basées sur la sélection du chemin plutôt que des modèles scriptPubKey fixes.

Expressivité du script et flexibilité du contrat

1. Taproot permet des conditions de dépenses complexes codées sous forme d'arbres if-else imbriqués, où chaque feuille correspond à un script distinct avec sa propre logique de verrouillage.

2. Des conditions verrouillées dans le temps peuvent coexister avec des chemins verrouillés par hachage, permettant des échanges atomiques, des canaux de paiement et des mécanismes de récupération sociale sans exposer les détails structurels.

3. Les opcodes CLTV et CSV restent entièrement fonctionnels mais fonctionnent désormais dans un environnement d'exécution unifié où toutes les branches partagent le même format de sortie.

4. Les développeurs peuvent intégrer une logique arbitraire, notamment des seuils multisig, des clés de délégation et des clauses de révocation, sans augmenter l'empreinte sur la chaîne, à moins que ces chemins ne soient utilisés.

5. L'évaluation de scripts récursifs est toujours interdite, préservant les principes de conception anti-DOS de Bitcoin tout en élargissant l'expressivité pratique grâce à l'élagage MAST.

Foire aux questions

Q1 : Les anciens portefeuilles Bitcoin peuvent-ils envoyer des fonds à des adresses Taproot ? Oui. Tout portefeuille prenant en charge le codage Bech32 peut générer des adresses P2TR valides et leur diffuser les dépenses de transactions. La compatibilité dépend du logiciel de portefeuille et non des restrictions au niveau du protocole.

Q2 : Les transactions Taproot nécessitent-elles de nouvelles clés privées ? Non. Les clés privées ECDSA existantes peuvent être converties en clés compatibles Schnorr à l'aide des méthodes de dérivation déterministes définies dans le BIP-340, préservant ainsi un contrôle total sur les actifs.

Q3 : Est-il possible d'identifier les résultats de Taproot en examinant les données brutes de la blockchain ? Oui. Les sorties P2TR commencent par la séquence d'octets 0x5120 suivie d'une clé publique modifiée de 32 octets, distinguable des préfixes P2WPKH (0x0014) et P2WSH (0x0020).

Q4 : Taproot élimine-t-il complètement le clustering d’adresses ? Non. Même si Taproot obscurcit la structure des scripts et réduit les vecteurs d'empreintes digitales, les heuristiques de clustering basées sur la topologie des graphes de transactions, le timing et le comportement de dépenses conjointes restent des outils médico-légaux viables.