Bitcoin évolue lentement mais sûrement. Même si aucune amélioration majeure n’a été ajoutée au protocole depuis 2017 avec SegWit, cela pourrait changer prochainement. La mise à niveau Schnorr / Taproot, développée depuis des années, devrait ainsi être verrouillée dans une poignée de jours.
Qu’est-ce que la mise à niveau Schnorr / Taproot ?
Schnorr / Taproot, ou plus simplement Taproot, est une modification du protocole Bitcoin ayant pour but principal d’accroître la confidentialité, la flexibilité et la scalabilité des contrats autonomes (smart contracts). Cette amélioration est un soft fork, c’est-à-dire une mise à niveau « rétrocompatible » du protocole, qui utilise la version 1 du système de versionnage apporté par SegWit.
Les améliorations de cette mise à niveau, décrites dans trois Bitcoin Improvement Proposals distincts, sont les suivantes :
L’algorithme de signature de Schnorr est une alternative à ECDSA, l’actuel algorithme de signature numérique utilisé dans Bitcoin. Il produit des signatures légèrement plus petites et possède une propriété de linéarité permettant la vérification par lots et l’agrégation des clés. Cette agrégation des clés rend possible la mise en place de schémas de multisignature par l’inscription sur la chaîne d’une seule clé publique agrégée (issue des clés publiques des participants) au lieu de toutes. Le déverrouillage des fonds se fait alors par la combinaison des signatures des participants au moyen du protocole sécurisé MuSig, développé pour l’occasion.
Taproot (« racine pivot » en français) est un système d’arbres syntaxiques abstraits merkélisés (MAST) permettant d’ancrer les conditions d’un contrat au sein d’un arbre de Merkle et de cacher ces conditions sous une clé publique agrégée. Lors du règlement, les personnes impliquées dans le contrat peuvent produire une signature pour dépenser les fonds « à l’amiable », auquel cas la transaction est semblable à une transaction classique et les conditions du contrat ne sont pas révélées. Les participants peuvent aussi exécuter la condition du contrat qui les intéresse en sélectionnant la branche correspondante. Taproot a donc pour avantage de ne pas dévoiler l’ensemble des conditions des contrats comme cela se passe actuellement dans Bitcoin avec Script.
La clé publique agrégée est légèrement modifiée pour prendre en compte les données du contrat et permettre la dépense coopérative. Cette clé de 32 octets est utilisée en tant qu’adresse de réception, dont le type est appelé « Pay-to-Taproot » ou P2TR, qui utilise la version 1 de SegWit et commence donc par bc1p.
Pour finir, Tapscript définit la sémantique des scripts utilisés dans Taproot. Il permet une gestion plus flexible des contrats par rapport à ce qui est fait avec Script actuellement.
La mise à niveau Schnorr / Taproot concerne ainsi essentiellement les contrats autonomes sur Bitcoin et améliore fondamentalement deux choses à leur sujet : leur scalabilité et leur confidentialité. En effet, en évitant de révéler l’ensemble des conditions des contrats (et en utilisant le plus souvent une signature simple), on protège la vie privée des utilisateurs et on réduit l’espace utilisé. Ce double avantage pourrait être mis à profit pour les transactions concernant Lightning : lors des fermeture coopératives de canaux on n’aura plus besoin de révéler l’entièreté du script, gagnant à la fois sur le plan des frais de transaction et sur celui de la confidentialité.
En revanche, pour ce qui est des paiements classiques (sur la chaîne), Schnorr / Taproot n’apporte pour ainsi dire rien de particulier. Tout d’abord, la mise à niveau n’offre pas de confidentialité supplémentaire, et va en réalité affaiblir l’anonymat sur la chaîne en ajoutant un nouveau type d’adresse à la longue liste des types existants. En effet, en diminuant l’homogénéité des types utilisés, on favorise l’analyse de chaîne permettant de tracer les bitcoins.
Ensuite, Schnorr / Taproot ne permet pas non plus de gagner en scalabilité pour ces paiements. Contrairement à ce qui avait été vendu, la mise à niveau n’intègre pas d’agrégation des clés entre les entrées transactionnelles et n’apporte pas ainsi la réduction de 25 % de la taille des transactions qui était annoncée.
Enfin, le fait que les sorties P2TR soient toujours encodées sur 32 octets (au lieu de 20) rend les transactions réalisant des paiements classiques plus lourdes de manière générale et annule par conséquent l’avantage de place gagné par la taille réduite des signatures de Schnorr.
Comment le soft fork Schnorr / Taproot va être activé ?
Bitcoin est un protocole décentralisé et, en tant que tel, ne peut pas être modifié de n’importe quelle manière. Non seulement son évolution requiert un accord général sur les changements à implémenter, mais demande aussi une coordination pour activer ces changements.
Pour Taproot, les changements ont déjà été plus ou moins approuvés par l’ensemble des acteurs de l’écosystème. En effet, contrairement à la mise à niveau SegWit qui était beaucoup plus controversée en 2016 / 2017 dans le cadre du débat sur la scalabilité de Bitcoin, il n’y a que peu d’opposition à cette nouvelle évolution, que ce soit de la part des développeurs, des mineurs ou des utilisateurs. La proposition Schnorr / Taproot est discutée depuis longtemps, formalisée depuis 2019 et a fait l’objet de nombreux essais et mises à l’épreuve. Son code a été intégré à l’implémentation principale Bitcoin Core depuis octobre 2020.
Cependant, bien que le contenu de la mise à niveau ne soit pas controversé, son activation a elle fait l’objet de débats plus soutenus.
Lors des précédents soft forks (l’encodage DER strict en 2013, OP_CHECKLOCKTIMEVERIFY en 2015, OP_CHECKSEQUENCEVERIFY en 2016 et SegWit en 2017), l’activation se faisait via le signalement des mineurs au sein des blocs qu’ils minaient. Ces soft forks ont été ce qu’on appelle des « Miner Activated Soft Forks » ou MASF, car ils s’activaient automatiquement une fois qu’une certaine proportion de mineurs signalaient leur approbation sur une période donnée.
Pourquoi passer par ce signalement ? Un soft fork est une restriction des règles de consensus et rend par conséquent les blocs construits avec les nouvelles règles valides selon les anciennes règles (compatiblité ascendante). Si la majorité de la puissance de calcul du réseau applique ce soft fork au même moment, alors cela évite toute scission de la chaîne : la puissance de calcul « force » les nœuds appliquant les anciennes règles à suivre la chaîne majoritaire, selon le principe de la chaîne la plus longue, comme cela serait réalisé dans la cas d’une attaque des 51 %. Le mécanisme de signalement permettait ainsi de s’assurer que la mise à niveau se passe sans encombre en requérant un haut niveau d’adhésion pré-activation.
Mais le signalement a également ses inconvénients. SegWit, la dernière mise à niveau du protocole Bitcoin, était censée être activée au moyen du BIP-9 qui demandait 95 % de la puissance de calcul. Toutefois, au bout de plusieurs mois, ce seuil était loin d’être atteint, le taux de signalement stagnant sous les 50 %, et la durée totale prévue approchait de l’expiration (mise à jour annulée).
Devant ce refus d’activer SegWit venant des grandes coopératives de minage, un inconnu utilisant le pseudonyme Shaolin Fry a mis au point le BIP-148 qui proposait de d’activer SegWit manuellement, sans le soutien des mineurs. Cette proposition était appelée « User Activated Soft Fork » et devait s’appliquer le 1er août 2017. Ce mouvement a gagné en popularité et a probablement influencé le New York Agreement et la mise en place du BIP-91, ce qui a fini par activer SegWit le 24 août 2017.
Cet épisode a aussi permis la création du BIP-8, qui est similaire au BIP-9, mais qui active la mise à niveau à la fin de la durée totale de signalement si la variable booléenne lockintimeout (littéralement « verrouillage à l’expiration ») est fixée sur true (« vrai »).
Lors des discussions autour de l’activation de Schnorr / Taproot qui ont eu lieu en 2020 et en 2021, il a été décidé d’utiliser une variante du BIP-8. Cependant, il existait toujours un point de désaccord autour de la variable lockintimeout (couramment abrégée en LOT) :
- Certains développeurs préféraient la configuration
LOT=truequi activait la mise à niveau à la fin de la période de signalement ; - D’autres préféraient
LOT=false, ce qui revenait de facto au fonctionnement du BIP-9 et annulait l’activation de la mise à niveau à l’expiration.
Les méthodes d’activation proposées différaient également sur d’autres aspects comme les timings à respecter.
Tout ceci s’est soldé par un compromis appelé Speedy Trial (« procès expéditif ») proposé le 6 mars 2021 par David Harding. L’objectif de cette proposition était de :
- Débuter le signalement rapidement ;
- Le pousser rapidement à expiration avec
LOT=falsepour inciter les mineurs à signaler et pour ne pas empiéter sur les alternatives (d’où son caractère « expéditif ») ; - Activer la mise à niveau de manière retardée dans le cas d’un signalement positif.
Cette méthode a été intégrée à Bitcoin Core 0.21.1 en avril et le signalement a débuté le 1er mai (au bloc 681 408). Pour que Taproot soit verrouillé, il faut que 90 % des blocs minés lors d’une période de 2016 blocs (environ 2 semaines) signalent leur approbation de la mise à niveau. La durée totale du signalement doit durer 6 périodes, soit environ 3 mois. Dans le cas d’un succès, Taproot sera activé au bloc 709 632, en novembre a priori.
Néanmoins, Speedy Trial n’a pas suffi à calmer les ardeurs des partisans de LOT=true, qui ont fini par créer une implémentation supplémentaire. Ainsi, le 16 avril dernier, le développeur luke-jr, bien connu dans la communauté et co-auteur du BIP-8, a mis en avant sa propre version de Bitcoin Core implémentant le signalement des mineurs avec une activation forcée de Taproot au bloc 709 632 quel que soit le résultat.
Le signalement des mineurs pour Taproot se déroule donc depuis le 1er mai 2021 (bloc 631408). Après deux périodes de signalement infructueuses, il semble que la dernière en date puisse être la bonne, ce qui signifie que la mise à niveau devrait être verrouillée dès mi-juin.
Développeurs, mineurs, utilisateurs : qui contrôle Bitcoin ?
Le débat autour de Schnorr / Taproot pose la question de la gouvernance de Bitcoin. En effet, il est difficile de comprendre les évènements autour de l’activation sans appréhender les mécanismes qui dirigent l’évolution du protocole Bitcoin.
Dans Bitcoin, on distingue ordinairement trois grandes catégories d’acteurs : les développeurs, qui maintiennent le code informatique du logiciel, les mineurs, qui se chargent de confirmer les transactions, et les utilisateurs qui envoient et reçoivent des transactions.
Les développeurs ne contrôlent pas le protocole. Ils éditent un logiciel que les nœuds du réseau font tourner comme bon leur semble. Si les opérateurs de nœuds refusent de mettre à niveau leur implémentation, alors le protocole restera le même. Cela ne veut pas dire que les développeurs n’ont aucune influence, mais simplement que la source qui donne au protocole sa direction se trouve ailleurs.
Le principe de signalement peut faire croire que les mineurs sont en charge du protocole mais ce n’est pas réellement la cas. En effet, si les mineurs choisissaient de confirmer les transactions d’un Bitcoin que personne n’utilise ni ne valorise, alors ils ne recevraient aucun revenu, rendant l’opération inutile. Les mineurs peuvent aussi choisir de ne pas miner voire d’attaquer la chaîne afin d’influencer potentiellement le choix des règles de consensus, mais ils ne peuvent pas les définir directement.
Ce sont par conséquent les utilisateurs qui décident des règles de consensus, en apportant de la valeur au bitcoin et en payant les frais de transaction. Les utilisateurs décident ainsi de valider des règles et les mineurs décident d’ajouter des blocs, le résultat étant une chaîne.
De cette manière, l’idée d’un User Activated Soft Fork n’est pas une idée si folle. Puisque ce sont les utilisateurs qui déterminent le protocole, ils peuvent après tout le faire directement. De plus, si les nœuds qui appliquent les règles du soft fork forment la majorité économique, alors tout est censé bien se passer, car la chaîne résultante sera presque certainement la chaîne majoritaire au niveau du taux de hachage.
Néanmoins, l’UASF semble ignorer le risque de scission de chaîne en cas d’une puissance de calcul trop faible. L’intérêt principal d’un soft fork étant d’éviter la scission (par « rétrocompatibilité »), l’UASF n’est ainsi pas forcément un bon plan pour effectuer une mise à niveau propre. D’où le fait de passer par un Miner Activated Soft Fork : en exigeant le signalement des mineurs, on s’assure autant que faire ce peu qu’une supermajorité de mineurs suivra les nouvelles règles le jour de l’activation, dans le but qu’il n’y ait pas de scission.
C’est pour cela que Taproot fait aujourd’hui l’objet d’un signalement : non pas pour valider le fait que les mineurs contrôlent Bitcoin, mais pour maximiser les chances d’une mise à niveau paisible.
Conclusion
Schnorr / Taproot est donc une mise à niveau qui apporte confidentialité, scalabilité et flexibilité aux contrats sur Bitcoin, ce qui sera très utile au fonctionnement du réseau Lightning. La méthode d’activation a été choisie non sans heurt mais cela semble aujourd’hui porter ses fruits, avec un verrouillage qui est désormais très probable. Quoi qu’il en soit, les débats autour de cette mise à niveau illustrent encore une fois la façon dont Bitcoin évolue en tant que système économique et les rapports de force en jeu.
Pour en savoir plus Taproot et sur les détails de son activation, je vous conseille le très bon article de Fanis Michalakis publié le mois passé. Je vous suggère également l’entrevue vidéo avec Sosthène, dans laquelle ce dernier aborde ces sujets.
