Les Développeurs Bitcoin (BTC) Ne Sont Pas D'accord Sur L'Activation De Taproot

Taproot a encore de la route à faire avant d’être actif sur Bitcoin (BTC). La gestion technique d’un réseau est de loin plus simple, que la gestion des milles et unes caprices des humains qui le composent.

Segwit se rappelle aux bons souvenirs de Taproot

Taproot est prêt à être déployé en soft fork suite à l’intégration des Bitcoin Improvement Proposals (BIP) 340 à 342 le 15 octobre 2020.

Les mauvaises expériences lors de l’activation de Segwit hantent encore les esprits des bitcoiners et notamment des développeurs.

A l’époque, les mineurs n’avaient pas joué le jeu la première année et, il avait fallu sortir une nouvelle proposition de mise en œuvre au milieu du processus d’activation pour leur mettre la pression.

L’une des propositions stipulaient que les nœuds devaient rejeter les transactions des mineurs n’ayant pas encore effectué la mise à jour vers Segwit, une contrainte pour accélérer l’adoption de ce dernier.

L’un des développeurs de Bitcoin Core, A.J. Towns, a interrogé 12 de ses pairs pour recueillir leurs idées quant à la gestion du soft fork à venir.

Ils s’accordent aujourd’hui sur les grandes lignes de la mise en œuvre de Taproot mais, le diable est dans les détails.

Towns a demandé aux développeurs la proportion de mineurs nécessaire signalant une mise à jour pour être certaine d’avoir une majorité suffisante – safe majority.

8 d’entre eux estiment que 85% à 95 % seraient suffisants. Le cas échéant, on s’exposerait à un risque de division du réseau : certains mineurs utiliseraient l’ancien code et d’autres le nouveau, créant 2 historiques de transactions contradictoires.

En l’absence d’un signalement d’activation par les mineurs, 7 des répondants indiquent que le flag-day qui activerait « par la force » la mise à jour via les nœuds, pourrait avoir lieu dès 12 à 18 mois après le début de l’activation.

Si le nombre de mineurs adoptant la mise à jour est insuffisant, les nœuds pourraient alors appliquer les règles de Taproot et valider uniquement les blocs des mineurs qui ont basculé vers ce dernier.

Les développeurs veulent d’abord voir si les mineurs et les utilisateurs effectueront la mise à jour de leur propre chef, avant de décider d’une date pour le flag-day.

Les 2 voies vers Taproot

Le déploiement de Taproot repose aujourd’hui sur 2 propositions qui ont tiré les leçons de Segwit. Elles reposent sur mélange de signalisation pour les mineurs et d’activation pour les utilisateurs du réseau.

La BIP8 de 2017 avancée par les développeurs Luke Dashjr et Shoalinfry, prévoit une période de signalisation pour les mineurs. En l’absence d’un nombre suffisant de mineurs activant la mise à jour et donc à défaut d’un consensus, un flag-day met automatiquement à niveau les nœuds BTC ayant téléchargé la v0.21 de Bitcoin Core

Ces nœuds rejetteraient les blocs et les transactions des mineurs ne supportant pas Taproot, pour les contraindre en théorie à adopter ce dernier afin d’éviter une perte de revenus.

La seconde proposition du développeur Matt Corallo fusionne la BIP8 et la BIP9. Cette dernière fut celle adoptée initialement pour l’activation de Segwit mais, elle s’était révélée inefficace.

Ce modèle hybride inclue une période de signalisation d’un an pour les mineurs. Si une « super-majorité » de mineurs ne bascule pas vers Taproot durant cette période, la mise à jour sera examinée 6 mois pour apporter éventuellement des modifications à la proposition.

La dernière étape est une période d’activation de 2 ans suivant la BIP8, avec un flag-day non obligatoire pour les nœuds, afin d’activer la mise à jour.

Au moins en dictature, tout le monde marche au pas de gré ou de force. Mais décentralisation oblige, un consensus est nécessaire pour que Taproot n’aboutisse finalement pas à un hard fork. Chaque voix compte, les 2 voies vers Taproot en ont conscience.