Le long chemin qui a mené à Taproot 

Taproot est le changement le plus important qui a été apportée au code de Bitcoin ces dernières années. Il a suivit la même méthode d’activation par soft fork qui avait été utilisée pour SegWit en 2017, à la différence près que cette fois-ci, le test (trial) a consisté à sécuriser 90% des blocs minés durant la période de 2016 blocs qui constitue une époque (environ 2 semaines).

D’un point de vue technique, Taproot reprend la crême de trois propositions d’amélioration majeures : les signatures de Schnorr (décrites dans le BIP 340), les branches de Merkle (également appelées MAST ou Merklelized Abstract Syntax Tree, décrites dans le BIP 114 et le BIP 117), ainsi que de nouveaux opcodes (Taproot, Grafroot, G’root et cross-input aggregation).

Comme l’expliquent les développeurs de Bitcoin Core Pieter Wuille, Jonas Nick et Anthony Towns dans leur proposition finale de Taproot BIP 341, leur travail ne consiste pas en une encapsulation de toutes les idées précédemment citées – car l’ajout d’un trop grand nombre de modifications du code impliquerait un processus de revue plus compliqué et une augmentation du risque d’ajouter des bugs indésirables. Dans le même temps, il ne s’agit pas non plus d’une tentative de pousser séparément ces propositions – une trop grade quantité d’upgrades épuiseraient les opérateurs indépendants de nœuds, tout en réduisant les avantages de cette approche sélective. Les auteurs du BIP ont choisi de le présenter comme un “compromis établissant un équilibre”, mais je préfère personnellement le voir comme un affinement qui a privilégié les meilleures fonctionnalités à disposition pour déboucher sur un efficacité optimale.

Taproot, c’est un peu comme la combinaison de trois plats pour lesquels on aurait réduit les portions, mais en conservant tout de même leur goût et leur valeur nutritionnelle pour chacun d’eux. On peut dire qu’il s’agit d’une autre avancée significative dans le processus visant à rendre Bitcoin plus efficace; au lieu d’une mise à l’échelle via de plus gros blocs comme le font de nombreux altcoins existants, le réseau cherche sans cesse à optimiser l’efficacité et la confidentialité des petits blocs existants pour que cela puisse bénéficier à l’ensemble des utilisateurs.

Dans un article précédent, j’avais fait l’éloge du mécanisme d’activation utilisé et soutenu que le chemin qui a conduit à cet upgrade reflète exactement le type de décentralisation dont Bitcoin a besoin pour réussir en tant que projet. Ici, je vais utiliser le court thread de Pieter Wuille pour tenter de raconter l’histoire de l’activation de Taproot et expliquer ce qui est supposé en découler.

Taproot – Depuis une discussion au restaurant en 2018 jusqu’au lock-in de juin 2021

Lorsque le bloc 687284 a été miné par F2Pool le 12 juin 2021, le soft fork Taproot avait été signalé par plus de 90% des mineurs qui avaient découvert des blocs durant cette époque. Ça signifiait concrètement que Taproot allait donc finalement pouvoir être activé au bloc de hauteur 709632, événement qui a eu lieu ensuite le 14 novembre 2021 (et ce premier bloc Taproot a lui aussi été miné par F2Pool d’ailleurs).

Cependant, le phénomène Taproot n’est pas apparu du jour au lendemain. L’idée de remplacer l’ECDSA (Elliptic Curve Digital Signature Algorithm) de Bitcoin par les signatures Schnorr est débattue depuis des années au sein de la communauté. Satoshi Nakamoto avait choisi l’ECDSA, moins efficace, car un brevet l’empêchait encore d’utiliser Schnorr jusqu’en 2008, et la norme open source, plus populaire à l’époque, disposait de toute façon de plus de librairies. Ainsi, même si sa conception n’était pas exactement idéale, elle était clairement la plus pratique et la plus raisonnable à ce moment là.

Et pourtant, les bitcoiners rêvaient d’ajouter les signatures Schnorr depuis des années déjà. Une proposition a été formalisée par Greg Maxwell en janvier 2018, quelques mois seulement après que SegWit ait été activé avec succès via UASF (User-Activated Soft Fork). À peu près au même moment, ce même Maxwell a rencontré ses collègues développeurs et cryptographes Pieter Wuille et Andrew Poelstra lors d’un diner à Los Altos, en Californie. Comme l’a décrit Wuille, ses pairs avaient eu une “idée vraiment cool pour cacher les racines Merkle dans des sorties de type P2PK” alors qu’il avait brièvement quitté la table.

Mais sur Bitcoin, le processus nécessaire entre une séance de brainstorming réussie et la présentation d’une proposition examinée en profondeur peut facilement dépasser 3 ans ou plus. Wuille a donc formalisé la première proposition Taproot en mai 2019 – il ne s’agissait alors que d’un court message à la mailing list des développeurs Bitcoin, mais le texte décrivait déjà les principales caractéristiques du soft fork. Les contributeurs à cette proposition incluaient Jonas Nick, Anthony Towns et Tim Ruffing – qui sont tous restés dans les parages pendant tout le cycle de développement.

Après quelques essais et des observations minutieuses, une version épurée de Taproot a été dévoilée par Wuille en octobre 2019. Cette fois, Wuille et ses collaborateurs ont amputé plusieurs éléments susceptibles de causer des complications inutiles et de potentiellement faire obstacle à l’efficacité recherchée (le plus célèbre étant l’abandon d’un octet de la conception initiale de la clé publique de 32 octets, car il “ne contribuait manifestement pas à la sécurité”). De même, ils ont quadruplé la profondeur des arbres de Merkle dans le but d’optimiser le code. Le graal du développement de Bitcoin c’est l’efficacité, et cette deuxième version collait parfaitement avec cet objectif.

Taproot a enregistré ses dernières modifications en août 2020, lorsque le tiebreaker des résidus quadratiques a été supprimé. Ici aussi, il s’agissait encore et toujours d’améliorer l’efficacité. Et lorsqu’une fonctionnalité n’apporte pas les avantages escomptés et entraîne une complexité supplémentaire, elle est tout bonnement supprimée. Ça fait partie de l’éthique du développement de Bitcoin: chaque ligne de code doit compter. Il ne s’agit pas seulement d’une forme de minimalisme, mais surtout d’une recherche constante de l’efficacité maximale.

En octobre 2020, une version finale de Taproot était enfin disponible pour les tests. Les développeurs l’ont merge dans une version préliminaire sur le testnet de Bitcoin Core 0.21, et c’est à peu près au même moment que les débats sur son activation ont commencé à être sérieusement abordés.

Entre-temps, tout au long du processus de développement, des auditeurs indépendants allaient jeter un coup d’œil au code open source. Après tout, c’était l’avenir de la monnaie qui était en jeu et personne n’aurait voulu laisser passer une erreur fatale qui aurait porté atteinte au bon fonctionnement d’un système comme celui de Bitcoin. Des bitcoiners comme Max Hillebrand ont donc offert des bounties (primes) à des experts afin qu’ils examinent en détail chaque ligne du code et s’assurent que rien de litigieux ou de non-optimal n’ait été inclus. Ça fait partie du charme offert par un système décentralisé et au code open source, où tout est visible et pour lequel n’importe qui dans le monde peut contribuer.

Pour ceux qui ont un peu de mémoire, la pierre d’achoppement qui a émergé à ce moment là consistait à montrer son soutien soit à LOT=true ou bien à LOT=false : dans le premier cas, les nœuds souverains pouvaient intervenir et rejeter les blocs des mineurs qui ne signalaient pas l’activation de Taproot à la fin de la période d’essai ; et dans le second cas, il n’y aurait aucune conséquence si les mineurs refusaient de se mettre à jour vers Taproot (leur donnant ainsi un droit de veto). Dans tous les cas, la période de signalement aurait duré une année entière.

Ce qui est important c’est que les utilisateurs avaient toujours en tête ce qu’il s’était passé en 2017 avec SegWit. À l’époque, les mineurs avaient refusé de signaler l’activation du softfork dans le temps d’essai imparti. Par conséquent, les nœuds souverains avaient pris sur eux même d’adopter la correction de la malléabilité des transactions – ce qui avait conduit au succès du mouvement UASF (User Activated Soft Fork).

Mais au milieu de ces débats houleux, David Harding avait présenté une proposition de “speedy trial” qui ne durerait que 3 mois et nécessiterait une supermajorité de 90% des blocs minés au cours d’une époque. Ça paraissait être la manière idéale de procéder, puisque tout le monde semblait d’accord pour dire que le code Taproot était prêt et que l’activation n’était qu’une affaire de consentement à mettre à jour le client Bitcoin Core.

Le speedy trial a toutefois connu des débuts difficiles, avec seulement une poignée de pools de minage (dont Slush Pool et Foundry USA) qui signalèrent l’activation de Taproot. Mais les bitcoiners comme à leur habitude n’ont rien lâché et ont continué à faire pression sur les mineurs pour leur demander de signaler leur soutien. Les utilisateurs de Twitter ont fait corps et ont affiché leur soutien à Taproot en utilisant l’émoji bloc vert à côté de leur nom. Toutefois à l’issue la première époque, la situation ne semblait pas bien engagée. Bien que F2Pool ait été le premier grand acteur à avoir rejoint le camp de l’activation, c’était toujours loin d’être suffisant.

La deuxième époque du trial n’a pas été concluante non plus, mais elle était toute proche cette fois. Durant cette période, des pools de minage tels que Poolin, Antpool, BTC.com et Binance Pool ont été poussés à rejoindre le camp de la signalisation. Au cours des derniers blocs de cette époque, c’est devenu évident que la troisième fois serait la bonne. À moins que les mineurs ne décident de revenir sur leur décision de soutenir Taproot, l’activation allait être verrouillée de manière imminente. Et c’est exactement ce qui s’est passé le 12 juin 2021.

Et ensuite ?

L’activation de Taproot allait donc pouvoir avoir lieu en novembre 2021, au bloc 709632. Mais d’ici là, il y avait encore beaucoup de pain sur la planche. Du côté des développeurs, les wallets allaient devoir être mis à jour et standardisés. Pour tirer parti des avancées en matière de confidentialité des multisigs, le format MuSig2 allait devoir établir une norme que tous les wallet allaient pouvoir utiliser. De même, les extensions PSBT allaient devoir être améliorées afin de communiquer avec les clés, les scripts et les signatures.

Du côté des utilisateurs, ils allaient devoir mettre à jour les clients de leurs nœuds pour une version supportant Taproot – la plus récente étant la 0.21.1. Il s’agissait et il s’agit toujours de l’étape la plus importante, car tous les efforts de codage et d’activation sont vains s’ils ne sont pas utilisés à leur plein potentiel. Évidemment, tout est facultatif et repose sur l’intérêt des opérateurs de noeuds souverains. Mais il y a des avantages indiscutables à cet upgrade, tant au niveau individuel qu’au niveau du réseau.

J’ai entendu parler de Taproot pour la première fois en 2019, dans un article d’Aaron van Wirdum. Il aura fallu environ deux ans pour que le code soit affiné puis examiné par la communauté, et une demi-année de plus avant que le speedy trial ne réussisse à verrouiller le soft fork avant son activation en novembre par la suite. Ça peut sembler long, mais c’est ainsi qu’il est normal de progresser dans un écosystème décentralisé et véritablement délibératif. Tout doit être optimisé dans les moindres détails, et indubitablement la performance doit primer sur la vitesse d’activation ou la pression exercée par certains acteurs du marché au cours des différentes phases.

Bitcoin est l’exemple parfait d’un système décentralisé qui prend en compte les opinions de tous les utilisateurs et donne à chacun suffisamment de temps pour exprimer ses préoccupations et ses critiques. Et il demeure peu probable que cela ne change à l’avenir : les mineurs et les opérateurs de nœuds exigeront toujours les niveaux de rigueur les plus strictes avant d’exécuter une nouvelle version du client, tandis que les développeurs saisiront chaque opportunité qui se présente à eux pour se démarquer via des ajouts constructifs ou bien des critiques précieuses.

Il reste encore et toujours des améliorations à apporter à la couche de base de Bitcoin et les propositions ne manquent pas, allant des Drivechains à OP_CheckTemplateVerify. Les développeurs travaillent dur afin de faire ce pour quoi ils excellent : tirer le meilleur parti possible de Bitcoin et repousser ses limites de manière créative et efficace.

Soutenez Bitcoin Takeover

Cet article est la traduction d’un texte original de Vlad Costea

N’hésitez pas à vous inscrire à sa newsletter, suivez le sur YouTube, Twitter ou Instagram et assurez vous de ne pas manquer ses podcasts

Pour le soutenir financièrement, reportez vous aux instructions dans ses différents posts.

Si vous voulez aussi m’encourager à continuer de publier des articles en français, vous pouvez me lâcher quelques sats ici: bc1qj0z6eu07wydhrgpky6qqsse3sn9yldvalw3rj5