Taproot : la mise à niveau de Bitcoin encore en attente

La communauté des développeurs de Bitcoin avance avec prudence. Implémenter une mise à jour du code n’est pas chose aisée : cela requiert un consensus quasi-absolu. L’expérience Segwit a laissé des traces, et il est hors de question qu’un nouveau soft fork provoque autant de dissensions. Même si Taproot est l’amélioration de Bitcoin attendue par tous, le processus d’implémentation sera long.

Le traumatisme Segwit

Bitcoin est un système parfaitement inclusif, mais aussi très élitiste. N’importe qui peut cloner le code de Bitcoin, l’annoter, ou soumettre des améliorations à l’ensemble de la communauté… Mais il ne suffit pas de proposer une bonne idée pour qu’elle soit mise en pratique !

Les BIP (Bitcoin Improvment Proposals) sont consciencieusement analysés par l’ensemble des développeurs. La valeur de Bitcoin réside grandement dans la robustesse de son code. Chaque amélioration est ainsi longuement étudiée et testée, afin qu’elle renforce la sécurité du système, et non l’inverse.

Cela donne donc souvent lieu à des débats d’experts… Cryptographes, mathématiciens et codeurs mettent leur paranoïa au service du réseau.

Même de légères modifications peuvent mener à des guerres intestines au sein de la communauté. Ce fut notamment le cas pour Segwit, qui a divisé les esprits jusqu’à provoquer la scission de la blockchain. C’est par ce désaccord fondamental sur la scalabilité de Bitcoin que Bitcoin Cash a vu le jour.

Ce fut une épreuve pour l’écosystème, et c’est à l’orée de cette expérience que les futures améliorations de Bitcoin seront implémentées. Le consensus doit être maximal : dans le cas de Segwit, 95 % des nœuds devaient approuver la mise à jour afin qu’elle soit implémentée.

Pour éviter les divisions, la méthode est différente pour Taproot. La mise à jour est programmée pour être rejetée par défaut au bout d’un an si le consensus n’est pas atteint. Si la communauté la valide, une période de six mois est prévue pour permettre aux développeurs de prévoir les modalités de son implémentation. Elle sera effective deux ans après, soit le délai maximal d’adoption d’un soft fork à 42 mois.

Taproot, qu’est-ce que c’est ?

Pour comprendre cette amélioration du code de Bitcoin, il faut connaître le fonctionnement de son système de script.

Pour commencer, Bitcoin permet de programmer des smart contracts. Une transaction Bitcoin n’est en fin de compte rien d’autre qu’une série d’exécutions conditionnelles, permettant de déplacer des coins d’un endroit à un autre. Le but d’un smart contract est de profiter de la non-répudiation du code pour effectuer une ou plusieurs transactions, consenties librement par les parties prenantes, sans passer par un tiers de confiance.

Lorsqu’on programme une transaction sur le réseau Bitcoin, elle est transcrite dans en langage informatique. Nul besoin de plonger dans sa syntaxe pour comprendre son fonctionnement. Il suffit d’avoir quelques notions à l’esprit.

Le système P2SH pour des transactions complexes

Pour réaliser une ou plusieurs transactions sur Bitcoin, il est nécessaire de prouver qu’on est bien propriétaire des coins que l’on souhaite déplacer. Cela est possible grâce aux signatures numériques. Elles permettent de prouver à l’ensemble du réseau que l’on est bien maître de la clé privée associée à telle ou telle adresse.

Le système s’appelle pay to script hash ou P2SH. Il permet de réaliser des transactions complexes qui peuvent, par exemple, nécessiter plusieurs signatures pour être validées.

Même si le P2SH permet de réaliser des smart contracts basiques (des séries de transactions conditionnelles), il a un défaut.

En effet, afin de prouver la validité du script, il est nécessaire de rendre publique l’intégralité de son contenu. À chaque fois que des bitcoins changent de main, leur nouveau propriétaire doit tout révéler au réseau. Cela présente deux inconvénients :

• La quantité de données à publier est importante, et elle est proportionnelle à la complexité des transactions à réaliser ;
• Le fait de rendre le script public est évidemment mauvais pour la confidentialité des parties engagées dans la ou les transactions. Cela diminue le niveau d’anonymat de Bitcoin.

Les MAST (Merkelized Abstract Syntax Trees)

Afin de pallier le premier problème, les cryptographes ont un procédé ingénieux.

Il repose sur les célèbres arbres de Merkle. Cette structure de données permet de produire un hash pour chaque condition d’exécution du script. Ces hashes sont ensuite regroupés dans l’arbre de Merkle, qui est alors haché à son tour. On appelle ce dernier hash la racine de l’arbre (Merkle root).

Cela confère alors une propriété très intéressante à notre script. Il suffit ainsi de rendre publique une seule condition d’exécution (effective) pour que l’ensemble du réseau puisse l’authentifier.

Cela améliore déjà légèrement la confidentialité de Bitcoin, étant donné que les conditions non remplies d’un script restent privées. Il faut juste que le réseau possède la racine Merkle et la structure de l’arbre (Merkle path) pour valider la transaction.

Les signatures de Schnorr

Sans entrer dans les détails, ce schéma de signature numérique permet d’agréger les multiples signatures requises pour une transaction.

Ce protocole d’authentification est également une preuve à divulgation nulle de connaissance, c’est-à-dire qu’il n’est pas nécessaire de connaître le contenu du script afin de prouver son authenticité.

Ainsi, une transaction multi-signature scriptée ne sera pas différente pour l’ensemble du réseau d’une transaction simple.

Taproot, l’implémentation ultime

Taproot combine les structures de données des MAST et les signatures de Schnorr.

Comme nous l’avons vu, afin que le réseau Bitcoin valide un script, il suffit, avec les MAST, de publier une seule condition d’exécution sur laquelle s’accordent les parties. Les signatures des parties sont agrégées et servent à prouver ce consensus.

Il est donc nécessaire avec Taproot de créer une condition d’exécution qui sera signée par les parties prenantes à la transaction. On l’appelle « fermeture coopérative ».

Toutes les autres conditions d’exécution « non coopératives » sont alors regroupées dans un autre script. Ce dernier sera haché, puis utilisé pour transformer la clé publique commune (résultant de l’agrégation des clefs publiques des parties).

Si les conditions de la coopération entre les parties sont réunies, il suffira de publier le script pour exécuter la transaction. Dans le cas contraire, il faudra révéler à la fois le script et la multi-signature originale pour appliquer les conditions alternatives.

Malgré l’impatience de la communauté, Taproot ne sera pas implémenté de sitôt. C’est la conséquence de l’anti-fragilité de Bitcoin. Au fur et à mesure des expérimentations, l’organisme se renforce. Les leçons de Segwit ont été bien assimilées, et le processus est désormais un peu plus long.