Dernière modification effectuée le 10.10.2023 17:20
Taproot est la première mise à jour d'ampleur du protocole Bitcoin depuis la mise en place de SegWit en 2017. Elle apportera essentiellement des améliorations en termes de confidentialité et d'efficacité des transactions, notamment lorsque ces-dernières impliquent des scripts complexes. Pour l'utilisateur moyen, elle passera donc relativement inaperçu, tandis qu'elle apportera de nombreux avantages dans le cadre d'une utilisation plus avancée de Bitcoin.
Pour bien comprendre les apports de Taproot, il faut prendre le temps de se pencher sur le fonctionnement des transactions Bitcoin. Classiquement, lorsqu'on souhaite dépenser des bitcoins dans une transaction, il faut signer cette transaction avec la clé privée correspondant à l'adresse où se trouvent ces bitcoins. C'est un fonctionnement auquel tous les utilisateurs réguliers de Bitcoin sont habitués, mais il ne s'agit en fait que d'un cas particulier du mécanisme général des transactions Bitcoin.
En effet, en toute généralité, pour dépenser des bitcoins il faut remplir toutes les conditions nécessaires du script qui verrouille ces bitcoins. Ainsi, dans le cas courant où l'on dépense des bitcoins en signant la transaction, c'est tout simplement parce que la condition à remplir pour déverrouiller le script est de fournir une signature provenant de la bonne clé privée. Mais il existe d'innombrables autres possibilités, avec des scripts aux conditions plus complexes :
Il est bien entendu possible de combiner ces conditions dans des scripts complexes, où plusieurs moyens différents permettent de déverrouiller les fonds. C'est par exemple le cas dans l'exemple ci-dessous, où plusieurs “chemins” sont possibles pour dépenser les 0.01 BTC.
Cependant, lorsqu'on déverrouille le script, il faut révéler l'intégralité des conditions possibles, même celles qui n'ont pas été utilisées, en plus de la preuve que la condition qui a effectivement servi a bien été satisfaite. Ce fonctionnement présente un double désavantage, à la fois en terme de confidentialité (puisque cela impose de révéler des conditions du script “pour rien”) et en terme d'espace de bloc et donc de frais de transactions (puisque les conditions inutilisées sont tout de même affichées dans le bloc). Ces aspects sont en passe de changer considérablement avec l'arrivée de Taproot.
La mise à jour Taproot apporte notamment deux éléments qui vont dans ce sens :
Les signatures de Schnorr ne sont pas seulement plus performantes (comprendre : plus rapidement vérifiables), elles présentent surtout une caractéristique de linéarité très intéressante pour les adresses et transactions multisignatures, qui deviendront indiscernables des adresses et transactions monosignatures, plus classiques. Combinées avec MAST, elles permettront également de ne révéler que la partie réellement utilisée d'un script, économisant ainsi de l'espace dans le bloc et conservant le secret quant aux autres conditions du script.
Dans notre exemple précédent, si Alice dépense seule les 0.01 BTC, avec le timelock, seule cette double condition “Alice signe ET le timelock a expiré” sera visible d'un observateur extérieur, qui n'aura aucune idée que les mêmes bitcoins pouvaient également être dépensé de 2 autres façons. C'est un gain important à la fois en termes de discrétion et d'économie sur les frais de transactions.
Ces gains, on l'a vu, s'appliquent également sur les transactions multi-signatures. Non seulement une transaction multi-signature ressemblera à n'importe quelle transaction simple, mais en plus elle bénéficiera de frais bien moins élevés comparé à actuellement.
La mise à jour Taproot est un soft fork. Cela signifie qu'elle modifie certaines règles de consensus tout en conservant une compatibilité avec les nœuds ne faisant pas la mise à jour et qui continueraient donc à suivre uniquement les anciennes règles du protocole. Une transaction suivant les règles de Taproot sera donc vue comme valide même par des nœuds n'ayant pas fait la mise à jour, mais l'inverse n'est pas forcément vrai et certaines transactions suivant les anciennes règles pourraient être perçues comme invalides par les nœuds mis à jour.
Le code de Taproot est d'ores et déjà présent dans Bitcoin Core, l'implémentation principale de Bitcoin. Il faut maintenant qu'il soit activé, c’est-à-dire que les nœuds se coordonnent pour commencer à appliquer les règles de Taproot tous en même temps. En effet, en l'absence d'une telle coordination, les mises à jour de Bitcoin seraient chaotiques, avec des disparités importantes dans les règles à appliquer et donc, finalement, un consensus éclaté.
Avec l'expérience acquise lors de l'épisode SegWit, c'est ce point précis de l'activation qui a été (et est toujours) la source de débats animés. Ainsi, même si Taproot fait consensus et que personne ne s'oppose à son activation dans Bitcoin, les avis sont plus divisés quant à la manière de le faire.
Lors d'un soft fork, deux grands mécanismes d'activation sont possibles. D'un côté, la mise à jour peut-être activée par les mineurs : on parle alors de Miner Activated Soft Fork (MASF). L'idée est la suivante : les mineurs ont un certain temps pour mettre à jour leur nœud vers la nouvelle version incorporant Taproot. Une fois qu'un mineur (ou, en pratique, une pool de minage) a effectué la mise-à-jour, il commence à l'indiquer dans tous les blocs qu'il produit. Cela permet à l'ensemble du réseau de suivre facilement, en observant les blocs, quel pourcentage du hashrate total de Bitcoin a fait la mise à jour et est prêt à appliquer les nouvelles règles associées. Si un certain seuil est atteint (pour Taproot il s'agit de 90% du hashrate) alors la mise à jour est activée et tous les nœuds utilisant la dernière version commencent à en appliquer les règles. Si la durée prédéfinie est dépassée sans que le seuil ne soit atteint, alors le soft fork est annulé (bien que l'on puisse ensuite retomber sur un autre mécanisme d'activation).
Un autre mécanisme possible est l'activation par les utilisateurs ou User Activated Soft Fork (UASF). C'est ce mécanisme qui a été utilisé en 2017 pour SegWit, lorsque l'activation par les mineurs a échoué. L'idée est assez simple : on définit une date, le flag day, à partir de laquelle tous les nœuds ayant la mise à jour commencent à appliquer les nouvelles règles, que les mineurs soient prêts ou non. Si une majorité économique de nœuds active la mise à jour de la sorte, cela force les mineurs à se mettre à jour également, car certains de leurs blocs risquent d'être considéré comme invalides par les nœuds à jour et seront donc refusés par ces derniers.
Dans le cas de Taproot, le débat a fini par se cristalliser sur un point précis : que faire en cas d'échec de l'activation par les mineurs au bout du temps imparti ? Il s'agit plus précisément de définir le comportement des nœuds ayant la mise à jour, dans le cas où l'activation par les mineurs échouerait. Devraient-ils ne rien faire, en attendant de décider d'un nouveau mécanisme d'activation, ou les nœuds devraient-ils au contraire automatiquement commencer à appliquer les règles de Taproot, et tenter de procéder ainsi à un UASF ? Ce comportement est conditionné par une variable dans le code du client Bitcoin, nommée LOT pour Lock-in On Timeout (“verrouiller en cas d'expiration”). Si cette variable est définie sur “faux” (false), les nœuds ne font rien si le seuil de 90% du hashrate signalant être prêt n'est pas atteint. Si cela devait arriver, on repartirait alors certainement dans de nouvelles discussions pour décider quoi faire. À l'inverse, si cette variable est définie sur “vrai” (true), alors les nœuds appliqueront automatiquement les règles de Taproot dès l'expiration de la période d'activation par les mineurs, que le seuil des 90% ait été atteint ou non.
Un compromis entre le deux camps a été (plus ou moins) atteint avec une nouvelle proposition intermédiaire : le Speedy Trial (“procès expéditif”). Les mineurs ont trois mois pour signaler être prêts pour la mise à jour et que soit atteint le seuil de 90% du hashrate se signalant sur une période de 2016 blocs consécutifs (environ 2 semaines). Si au cours d'une période ce seuil est atteint, alors l'activation de Taproot est acquise et aura lieu automatiquement au bloc 709 632 (donc en novembre a priori). Si au bout de la sixième période, et donc après 3 mois, les 90% ne sont toujours pas atteint, alors l'activation échoue et les différentes parties prenantes devront de nouveau se mettre d'accord sur une méthode d'activation. Ce délai de 3 mois, raccourci par rapport au MASF habituel, a donc pour objectif de permettre aux utilisateurs d'éventuellement lancer un UASF si le MASF échoue sans avoir eu à perdre une année entière.
Ce compromis n'a pas convaincu tous les promoteurs de LOT=true, comme on peut s'en douter. Certains d'entre eux ont donc lancé un client Bitcoin alternatif à Bitcoin Core, qui est en tout point identique à Bitcoin Core à ceci prêt que LOT y est défini sur “vrai. Les nœuds utilisant ce client suivront donc le calendrier de Speedy Trial comme tous les autres mais, en cas d'échec, ils commenceront malgré tout à appliquer les règles de Taproot à partir du bloc 709 632.
Le signalement dans le cadre de Speedy Trial a débuté comme prévu au bloc 681 408, miné le 1er mai dernier aux alentours de 22h30. Lorsqu'un mineur a mis à jour son (ou ses) nœuds et est donc prêt à activer les règles de Taproot, il l'indique dans le numéro de version du bloc. Il faut donc bien comprendre que l'activation par les mineurs n'est pas un vote par ces-derniers indiquant s'ils cautionnent ou non Taproot (cette discussion a déjà eu lieu). Il s'agit simplement d'un moyen de s'assurer que suffisamment de mineurs sont prêts avant d'activer réellement Taproot, afin que la mise à jour soit aussi douce que possible.
Il est donc possible de suivre l'activation de Taproot par les mineurs en observant les blocs produits. Le site taproot.watch propose une visualisation de l'activation, où les blocs signalant Taproot sont indiqués en vert. Comme on le remarque, il est déjà acquis que Taproot ne sera pas activé lors de la première période, car plus de 10% des blocs de cette-dernière ne signalaient pas Taproot. C'était cependant attendu et bon nombre d'observateurs estiment que l'activation a plus de chances d'arriver autour de la troisième période.
