COMMENT BITCOIN DEVRAIT ÊTRE AMÉLIORÉ À L'AVENIR

L'historique des mécanismes d'activation de la mise à niveau de Bitcoin éclaire une opinion sur la manière d'apporter des modifications de protocole à l'avenir.

L'une des questions les plus controversées de Bitcoin au cours des cinq dernières années a été de savoir comment activer les soft forks. De nombreux mécanismes différents utilisés dans l'histoire de Bitcoin pour activer de nouvelles fonctionnalités sur le réseau, dont l'itération a généralement évolué dans le but de rendre le déploiement des fonctionnalités aussi sûr et non perturbateur que possible. Jusqu'en 2017, il y avait un consensus général et peu de désaccords car les mécanismes d'activation ont changé, mais lors du déploiement de Segregated Witness (SegWit), cela a changé.

SegWit est devenu leproblème qui a suscité des désaccords et des controverses sur la façon dont les fonctionnalités devraient être activées sur Bitcoin pour la première fois. Après le déploiement initial du BIP9, dépendant de la signalisation des mineurs pour verrouiller les règles d'application, une grande majorité de mineurs et de pools miniers ont refusé de signaler l'activation avec leurs blocs. À l'époque, de nombreux utilisateurs sont devenus furieux que les mineurs retardent l'activation d'une nouvelle fonctionnalité et la tiennent en otage avec des demandes de hard fork pour augmenter la taille du bloc (quand, pourrais-je ajouter, SegWit a réalisé une augmentation de la taille du bloc via un soft fork ), et l'ensemble de l'écosystème était rempli d'informations complètement inexactes sur SegWit dans le but de susciter une opposition à la fonctionnalité elle-même sur la base de mensonges éhontés.

BIP148 et le soft fork activé par l'utilisateur (UASF) ont fini par pousser les mineurs à activer SegWit, et l'un des gros blocs push a été annulé, laissant l'autre bifurquer et finalement s'effondrer. Mais depuis lors, les Bitcoiners ont généralement évité d'avoir la conversation sur la façon dont les nouvelles fonctionnalités devraient être déployées et activées. Le sujet est devenu controversé au point d'être presque tabou.

Je pense qu'il vaut la peine de passer par une visite de haut niveau de certains des mécanismes d'activation passés proposés et utilisés avant d'entrer dans la façon dont je pense personnellement que les mises à niveau devraient être gérées à l'avenir. Notez que ces mécanismes peuvent être utilisés aussi bien pour les fourches dures que pour les fourches souples, la seule différence est qu'une séparation de chaîne est garantie avec une fourche dure, et uniquement possible dans une fourche souple si les choses tournent mal.

Il s'agit de la tristement célèbre citation de Satoshi Nakamoto après avoir mis en œuvre la limite de taille de bloc d'origine, expliquant comment elle pourrait éventuellement être augmentée à l'avenir si les utilisateurs le jugeaient nécessaire. (Il convient également de noter que lorsque les gens l'ont appelé au début, Nakamoto était contre l'idée et a spécifiquement répondu avec la citation ci-dessus expliquant pourquoi cela ne devrait pas être fait avant d'en avoir besoin. Le dernier commentaire que Nakamoto ait jamais fait sur la question de taille de bloc, trouvé ici, a également explicitement reconnu que c'était finalement le choix des utilisateurs de le faire ou non.) 

il s'agit d'une «activation du jour du drapeau», où une hauteur de bloc ou un horodatage est sélectionné, et les nœuds mis à niveau commencent simplement à appliquer de nouveaux règles à ce moment-là. Il n'y a pas de signalisation publique ou de coordination visible, les gens téléchargent simplement le nouveau client et tous ceux qui ont mis à niveau commencent à appliquer au moment choisi, et ceux qui n'ont pas mis à niveau ne le font pas.

C'est ainsi que pay to script hash (P2SH) a été activé. Les activations du jour du drapeau sont, techniquement parlant, une forme de soft fork activé par l'utilisateur, étant donné que ce sont les nœuds du réseau qui s'engagent à activer une nouvelle fonctionnalité et à appliquer ses règles. Le problème avec les jours de drapeau est qu'ils ne fournissent aucun signal public indiquant quel pourcentage de mineurs prétendent appliquer de nouvelles règles, afin que chacun puisse évaluer le risque potentiel et la probabilité qu'une scission de la chaîne se produise. Les jours du drapeau n'ont pas été utilisés depuis un certain temps.

BIP9

BIP9 a été développé afin de réduire davantage le risque de rupture de chaîne lors du déploiement des fourches souples. L'idée sous-jacente était que les mineurs incluent un signal dans les blocs qu'ils exploitent, avec un nouveau logiciel de nœud ne déclenchant l'activation de nouvelles fonctionnalités que si un seuil (95%) de mineurs en période de difficulté signalent d'activer la fonctionnalité. Cela donnerait une indication publique du nombre de mineurs qui appliquaient la nouvelle fonctionnalité avant que les nœuds ne commencent à appliquer la nouvelle règle. De toute évidence, les mineurs pouvaient mentir et signaler faussement, mais l'idée était qu'il n'y avait aucune raison économiquement rationnelle de le faire. CheckLockTimeVerify et CheckSequenceVerify ont tous deux été déployés à l'aide de BIP9, et l'implémentation originale de Segregated Witness a également été déployée avec lui.

Le gros inconvénient d'un déploiement BIP9, comme en témoigne SegWit, est qu'une minorité de mineurs peut bloquer l'activation d'une fonctionnalité en refusant de signaler. Sans déployer quelque chose une seconde fois en utilisant un mécanisme d'activation différent, BIP9 donne aux mineurs un de facto où ils peuvent empêcher une nouvelle fonctionnalité de s'activer sur le réseau. Ce mécanisme d'activation donne donc aux mineurs un contrôle disproportionné sur ce qui est ajouté au Bitcoin ; les mineurs sont des fournisseurs de services aux utilisateurs et aux HODLers, et ne devraient donc pas avoir une telle influence surdimensionnée dans l'activation des fonctionnalités.

BIP148 ET UASF

BIP148 a créé un énorme précédent et a mis en œuvre un nouveau mécanisme d'activation jamais vu auparavant ; il n'a pas été conçu simplement pour activer une fonctionnalité dans son propre déploiement, mais également pour garantir que l'activation a eu lieu pour le déploiement BIP9 précédent de SegWit. C'était la raison de la date limite du 1er août. À partir du 1er août, la dernière période d'ajustement de difficulté de deux semaines pour la signalisation des mineurs avant la fin de la fenêtre d'activation de SegWit, les clients BIP 148 ont appliqué par consensus l'exigence que tous les blocs de cette dernière fenêtre signalent l'activation de SegWit.

Ce mécanisme était une nouvelle conception d'activation qui n'était pas nécessaire ou utilisée auparavant, et a été mis en place pour corriger ce qui était considéré comme une lacune majeure de BIP9 : la capacité des mineurs à bloquer l'activation de fonctionnalités qui, autrement, faisaient l'objet d'un consensus.

BIP91

BIP91 est un autre schéma d'activation unique déployé en 2017 en relation avec SegWit. Les mineurs de l'époque n'étaient pas disposés à céder à l'ultimatum de BIP148, mais s'inquiétaient en même temps des conséquences pour Bitcoin si BIP148 s'activait sans que les mineurs ne signalent et provoquent la scission de Bitcoin en deux chaînes de blocs parallèles. BIP91 a été créé afin de trouver un compromis qui permettrait à tout le monde de rester synchronisé sur la même blockchain.

Il a établi un seuil de 80%, où si autant de mineurs signalaient dans une période de difficulté pour activer SegWit, il commencerait à rendre orphelins tous les blocs qui ne signalaient pas (similaire à BIP148). L'objectif était de garantir que si BIP91 était activé, il resterait synchronisé et compatible avec BIP148, ce qui déclencherait alors le déploiement BIP9 original de SegWit, en gardant tout le monde sur la même chaîne. Le but était de donner aux mineurs une excuse pour "être ceux qui déclenchent l'activation".

BIP8

BIP8 était le mécanisme proposé pour remplacer BIP9 en raison de la situation survenue lors de l'activation de SegWit. L'objectif de conception était d'avoir un mécanisme de déploiement où les mineurs atteignant un seuil de signalisation (90%) pourraient activer la proposition à tout moment donné dans la fenêtre d'activation, mais de créer un mécanisme où il était possible de garantir qu'un fork est activé si suffisamment de mineurs refusent de signaler.

C'est la variable "lockinontimeout". S'il est défini sur vrai, alors dans la dernière période de signalisation, les règles de consensus imposeront que tous les blocs de cette période doivent signaler l'activation, tout comme BIP148, pour garantir que la nouvelle fonctionnalité s'active.

ESSAI

essai rapide a été la façon dont Taproot a été activé avec succès. C'était pour le moins un choix très controversé de mécanismes d'activation. En fin de compte, Speedy Trial fonctionne comme un déploiement d'activation BIP9, sauf que la fenêtre d'activation est beaucoup plus courte et que le seuil de signalisation est le même qu'avec BIP8 (90%). Une partie de la justification de l'utilisation de Speedy Trial était que si quelque chose avec un consensus ne s'activait pas, un déploiement BIP8 LOT=True pourrait être publié par la suite.

De nombreuses personnes, dont moi-même, considéraient Speedy Trial comme un pas en arrière en termes d'amélioration des mécanismes d'activation des fonctionnalités.

ET MAINTENANT?

Le fiasco d'activation de SegWit en 2017 a démontré la capacité d'une petite minorité de mineurs à interférer avec le consensus du réseau et le déploiement de fonctionnalités, ce qui a dû être corrigé par un déploiement incroyablement compliqué de plusieurs mécanismes d'activation différents simultanément, ce qui a compliqué les interactions incitatives entre eux. C'était une situation incroyablement risquée qui a heureusement fonctionné à la fin, mais cela aurait très bien pu tourner au désastre.

À mon avis, tout l'intérêt de dépasser le BIP9 était d'éviter de recréer à nouveau le potentiel d'une telle situation. Certains diront que Speedy Trial le fait en raison d'un délai beaucoup plus court avant la fermeture d'une fenêtre d'activation, mais je dirais que ce n'est pas le cas. Il présente toujours le risque d'échec d'une activation en raison de la malveillance ou de l'absence de réponse d'une minorité de mineurs, et surtout, donne l'impression sur le plan social que les mineurs sont capables de "veto" le consensus parmi les autres acteurs du réseau.

C'est à cela que je pense que les mécanismes d'activation se résument à long terme. Alors que Bitcoin continue de croître, de plus en plus d'utilisateurs sans instruction vont entrer dans l'écosystème. Dans ce processus d'apprentissage, ils observeront tout ce qui se passe et, plus important encore, ils examineront les mécanismes d'activation à travers le prisme de "Que se passe-t-il ici, qui décide si quelque chose s'active ou non ?" Développeurs ? Mineurs ? Entreprises? C'est la question, et ce sont les réponses, que la plupart des nouveaux utilisateurs auront à l'esprit lorsque nous allons déployer de nouvelles fonctionnalités et mises à niveau sur le réseau.

Les réponses auxquelles les gens arriveront finalement deviendront une prophétie auto-réalisatrice à cet égard, si les utilisateurs finissent par voir les mineurs comme les décideurs, alors la plupart des utilisateurs se tourneront vers les mineurs. Si les utilisateurs finissent par considérer les développeurs comme les décideurs, ils se tourneront vers les développeurs. La façon dont les Bitcoiners abordent cette question maintenant créera un précédent sur la façon dont les futurs utilisateurs gèrent les choses. Il y a beaucoup d'opinions différentes sur la façon dont l'activation doit être gérée, mais dans l'intérêt de ne pas mettre de mots dans la bouche des autres, je vais m'en tenir à décrire la mienne.

Je ne pense pas que Bitcoin Core ou les mineurs devraient être impliqués dans le processus d'activation dans le rôle de déployer de nouvelles versions d'activation, ou dans une position où ils sont capables d'opposer leur veto ou de bloquer quelque chose de l'activation. À l'avenir, je pense que toutes les nouvelles fonctionnalités déployées via un UASF utilisent BIP 8 LOT=True. Je pense qu'il est important que le précédent que nous établissons pour l'avenir soit celui d'une organisation de base qui ne provient pas systématiquement d'un groupe identifiable considéré comme l'arbitre des fonctionnalités activées ou non dans le protocole Bitcoin.

Si, à l'avenir, nous créons le précédent des personnes extérieures à Core étant celles qui proposent l'activation, nous créons le précédent d'un niveau plus élevé de scepticisme envers le changement en général. Nous évitons de créer la perception sociale pour les nouveaux utilisateurs que les développeurs décident de ce qui se passe ou ne se passe pas. Cela placerait une barre très haute pour l'adoption de nouveaux changements et garantirait que la barre reste élevée au lieu de se transformer en une dynamique d'utilisateurs s'en remettant à des experts pour décider de ce qui se passe. Les activations peuvent se produire via des clients externes, la prochaine version du Core activant de nouvelles fonctionnalités si elles ont été activées avec succès via des clients corrigés.

Cela peut permettre à chaque "client d'activation" d'être utilisé temporairement lors du déploiement d'une fonctionnalité, tout le monde revenant à Core après une activation réussie, évitant ainsi d'avoir à maintenir des clients de longue durée en dehors de Core tout en supprimant le processus d'activation des développeurs Core.

Certains pourraient dire que cela crée un risque de rupture de chaîne lors des fourches souples, mais la réalité est que les ruptures de chaîne sont toujours possibles lors d'une fourche souple. Avec LOT=True, le point auquel un fork se produira sera connu à l'avance s'il devait se produire. Si la chaîne va se diviser, cela se produira pendant la période de signalisation finale de l'activation lorsque le premier bloc ne signalant pas l'activation est miné. Cela définit une période de temps cohérente et prévisible au cours de laquelle cela se produira si tel est le cas, par opposition à tout point arbitraire après l'activation lorsqu'un mineur n'appliquant pas les nouvelles règles exploite un bloc violant cette règle.

S'il y a vraiment consensus pour une nouvelle fonctionnalité, alors la majorité de l'économie utilisera un client pour l'activer, et une telle scission en chaîne sera une perturbation et un inconvénient mineurs. S'il n'y a pas de consensus pour une nouvelle fonctionnalité, alors encore une fois, une telle division de chaîne ne devrait être qu'une perturbation et un inconvénient mineurs, car une infime minorité se débranche du réseau. Ils seront laissés avec la décision de continuer à utiliser une chaîne de fork minoritaire ou de céder et de revenir au réseau Bitcoin.

Bitcoin est finalement un système axé sur le marché, où le consensus est atteint volontairement. Je crois que les tentatives visant à empêcher que ce processus ne devienne désordonné sont à la fois malavisées, manquent la nature fondamentale du système, et conduiront inévitablement à un contrôle social plus centralisé et à une perception de la prise de décision descendante si les gens essaient constamment d'éliminer le désordre d'arriver à consensus. Nous devrions adopter ce processus et cesser d'essayer de le contrôler.

En fin de compte, il s'agit simplement de mon opinion personnelle sur la façon dont les choses devraient être faites, et il existe de nombreuses opinions plus diverses. Les gens ne devraient pas hésiter à donner leur avis sur cette question. Il est temps pour nous de commencer à avoir cette conversation au lieu de la remettre constamment à plus tard et de laisser l'inertie de la dynamique sociale prendre lentement la décision à notre place.