Les développeurs de Bitcoin toujours divisés sur les détails de l'activation de Taproot

Le code de Taproot, la plus grande mise à niveau de Bitcoin depuis des années, est finalisé eta été intégré dans une prochaine mise à jour. Seulement, il n’est pas encore prêt à être déployé car les développeurs de Bitcoin ont des opinions divergentes sur la meilleure voie vers l’activation.

Taproot améliorera les capacités des contrats intelligents de Bitcoin en implémentant un nouveau système de signature numérique, Schnorr. Cette mise à niveau nécessite un « soft fork » du code Bitcoin, et plusieurs propositions concurrentes existent quant à son activation.

Dans le but d'accélérer les discussions sur la mise en œuvre, le contributeur de Bitcoin CORE, AJ Towns, a récemment interrogé 12 autres développeurs qui ont été actifs dans le processus de mise en œuvre pour recueillir leurs réflexions sur ce à quoi devrait ressembler l'activation.

Sur le même sujet : L'avenir du Bitcoin : comment une mise à niveau à venir pourrait améliorer la Politique de confidentialité et la scalabilité

Le résultats de l'enquêtemontrent que, si les développeurs sont globalement d'accord sur la vision globale de l'activation de Taproot, ils divergent sur les détails. Alors qu'ils débattent des détails, la réflexion prudente et prudente du développeur peut sembler tatillonne aux yeux des non-initiés.

Mais cela montre que les mises à niveau dites « soft-fork » comme Taproot ne sont pas des Événements entièrement sans risque – et que le spectre de le soft fork controversé de Segwita hanté les discussions.

Propositions d'activation de la racine pivotante, expliquées

L'augmentation de la charge de transaction Segwit était le dernier soft fork de Bitcoin, ou une mise à niveau « rétrocompatible », ce qui signifie que les logiciels exécutant l'ancienne version du code peuvent toujours interagir avec la version mise à niveau.

L'activation de Segwit s'est déroulée sans heurts et a nécessité des ajustements en cours de route, les mineurs n'ayant pas adopté la mise à jour au cours de sa première année. Pour KEEP l'échec de la mise à jour, une nouvelle proposition d'implémentation a été adoptée en cours de processus. Afin de faire pression sur les mineurs pour qu'ils effectuent la mise à jour, une proposition suggérait même que les opérateurs de nœuds (les utilisateurs Bitcoin qui utilisent le logiciel Bitcoin et KEEP une copie de son registre) rejettent les transactions des mineurs n'ayant T mis à jour SegWit afin d'accélérer son adoption.

Sur le même sujet : Taproot a été intégré à Bitcoin CORE: voici ce que cela signifie

Dans un monde parfait, les utilisateurs de nœuds et les mineurs effectueraient des mises à niveau simultanément pour garantir qu’aucun conflit ne « divise » la chaîne – ou n’entraîne deux factions rivales prenant en charge deux versions différentes du code de Bitcoin.

Même si Taproot est une mise à niveau non controversée, la mémoire de Segwit rend les développeurs prudents lors de l'évaluation de cette dernière mise à niveau.

Deux propositions

Deux des principales propositions d'implémentation de Taproot reposent sur un mélange de signalisation des mineurs et d'activation des utilisateurs. Le BIP 8, introduit en 2017 par les développeurs Bitcoin Luke Dashjr et Shoalinfry, inclurait une période de signalisation pour les mineurs ; si suffisamment de mineurs ne s'activent T pour parvenir à un consensus sur la mise à niveau, un « jour de signalement » pour l'activation mettrait automatiquement à niveau les nœuds Bitcoin ayant téléchargé la version 0.21 de Bitcoin CORE.

Ces nœuds rejetteraient les blocs et les transactions des mineurs qui ne prennent pas en charge Taproot. En théorie, cette méthode inciterait donc les mineurs à adopter le nouvel ensemble de règles de peur de perdre des bénéfices.

Dans une deuxième proposition d'implémentation de Taproot, Modern Softfork Activation du développeur CORE Matt Corallo, fusionne BIP 8 avec BIP 9 (ce dernier étant la proposition initialement adoptée pour activer Segwit mais qui s'est avérée inadéquate).

Le modèle hybride de Corallo prévoit d'abord une période de signalisation d'un an pour les mineurs. Ensuite, si une majorité écrasante de mineurs ne procède pas à la mise à jour pendant cette période, la mise à niveau sera soumise à un examen de six mois afin d'apporter des modifications (le cas échéant) à la proposition.

La troisième et dernière étape est une période d’activation de type BIP 8 de deux ans, avec un jour de drapeau non obligatoire pour que les utilisateurs du nœud activent la mise à jour.

Ce que pensent les développeurs de Bitcoin

Pour la première question de son enquête, AJ Towns demande aux développeurs quel pourcentage de mineurs doit signaler une mise à niveau pour être considéré comme une majorité sûre. Huit d'entre eux estiment qu'un pourcentage minimum de 85 à 95 % serait suffisant. L'idée est que tout pourcentage inférieur risque de provoquer une « scission » du réseau, certains mineurs exécutant l'ancien code et d'autres le nouveau, ce qui créerait deux historiques de transactions contradictoires.

En l'absence d'activation signalée par un mineur, sept répondants estiment que l'activation imposée par les nœuds pourrait intervenir 12 à 18 mois après le début de l'activation. Si trop peu de mineurs adoptent la mise à niveau, les nœuds pourraient appliquer les règles Taproot et n'accepter que les blocs provenant de mineurs ayant également signalé la mise à niveau.

Dans un monde parfait, les utilisateurs de nœuds et les mineurs effectueraient des mises à niveau simultanément pour garantir qu’aucun conflit ne « divise » la chaîne – ou n’entraîne deux factions rivales prenant en charge deux versions différentes du code de Bitcoin.

Presque tous les développeurs interrogés souhaitent attendre de voir si les mineurs et les utilisateurs adoptent la mise à niveau d’eux-mêmes avant de décider d’une date précise pour le jour du drapeau (s’il y a suffisamment de support précoce, un jour du drapeau peut ne pas être nécessaire du tout).

Si l'activation ne se fait T de manière volontaire, une activation le jour de la mise à jour est la dernière option envisageable. La plupart des répondants étaient favorables à un jour de mise à jour obligatoire pour signaler automatiquement la mise à jour. Cela signifierait que les nœuds mis à jour rejetteraient les blocs des mineurs n'ayant T signalé la mise à jour.

Désaccords sur les détails les plus fins

La soi-disant signalisation forcée pendant le jour du drapeau aurait l'avantage de faire de Taproot le paramètre par défaut sur tout nœud Bitcoin CORE exécutant la version 21 ; à leur tour, ces nœuds n'accepteraient que les données de bloc des mineurs qui ont également signalé la mise à jour, donc en théorie, cela encouragerait les mineurs à effectuer une mise à niveau de peur de perdre leur activité.

Mais que se passe-t-il si les mineurs ont des utilisateurs de nœuds qui acceptent leurs blocs ?

Il y a un inconvénient à la signalisation forcée : si trop de mineurs et d'utilisateurs de nœuds n'acceptent T Taproot et refusent de mettre à jour leur logiciel, le réseau pourrait se scinder en deux chaînes concurrentes. Si l'intérêt économique est suffisant pour soutenir l'« ancienne » version de Bitcoin, il pourrait en résulter deux actifs concurrents.

Ce résultat explique en partie pourquoi certains développeurs, comme Matt Corallo, pensent que la signalisation forcée est inutile.

Taproot n'ayant guère suscité de controverse, forcer la signalisation de la mise à niveau représenterait un risque politique, affirme-t-il. Il considère cette méthode d'activation comme un vestige du « soft fork activé par l'utilisateur » de Segwit, une proposition visant à activer Segwit par des moyens similaires après l'échec des mineurs à adopter la mise à niveau. Segwit était très controversé et politiquement controversé. Taproot ne l'est pas, mais Corallo estime que la signalisation forcée risque de le rendre ainsi.

Dans son article, Towns écrit que la signalisation obligatoire serait un moyen d'appliquer définitivement l'activation de Taproot à l'échelle du réseau après qu'un consensus suffisant ait été établi par le biais de discussions et du soutien des mineurs.

« Si vous souhaitez maximiser le nombre de nœuds qui appliqueront les règles si un jour de drapeau se produit, mais également choisir le jour de drapeau uniquement après qu'une tentative d'activation initiale est déjà largement déployée, alors vous n'avez pas d'autre choix que de rendre la signalisation obligatoire lorsque le jour de drapeau se produit », écrit Towns.

Qu’est-ce qui retarde ?

Towns présente dans l'enquête une proposition d'activation alternative, assortie d'un délai d'activation de quatre ans. Comme toujours dans les discussions sur le développement de Bitcoin , cette proposition a également suscité une certaine opposition.

« Une fois que la décision d'activation bénéficie d'un soutien massif de la part des développeurs et des utilisateurs, plus le délai d'activation est long (au-delà de ce qui est pratiquement nécessaire aux mineurs pour effectuer une mise à niveau en toute sécurité), plus les problèmes peuvent se multiplier », a déclaré Eric Lombrozo, ancien développeur de Bitcoin CORE. dit à Towns sur Twitter.

Mis à part les risques, si la plupart des développeurs et des Bitcoiners pensent que Taproot est une option pour une mise à niveau, son activation ne devrait T prendre quatre ans, d'autant plus qu'elle est déjà en préparation depuis si longtemps.

Après tout, si Taproot est en préparation depuis 2018, les mineurs et les opérateurs de nœuds T devraient-ils pas savoir à quoi s'attendre ?

En tant que PDG de Blockstream, Adam Backmets-le sur Twitter« La racine pivotante ne peut T être une surprise après plusieurs années. »