Activation moderne de la fourche souple · Blog de BlueMatt

10 janvier 2020
Ceci a été initialement publié sur la liste de diffusion Bitcoin-dev ciblant un public technique, mais est conservé ici car il présente un intérêt plus général. Les exigences et les objectifs de l’activation des soft forks sont particulièrement intéressants.

Il existe une série de conceptions soft-fork qui ont récemment fait de bons progrès vers la mise en œuvre et l'adoption future. Cependant, pour diverses raisons, les méthodes d’activation ont fait l’objet de discussions limitées. J'aimerais rouvrir cette discussion ici.

Il vaut probablement la peine de revoir les objectifs des soft forks et leurs méthodes d’activation pour commencer. Il m'en manque probablement quelques-uns, mais quelques exigences de base :

1) Évitez d’activer face à une objection importante, raisonnable et dirigée. Période. Si quelqu'un a une utilisation raisonnable et bien acceptée du Bitcoin qui fonctionne aujourd'hui, n'a aucune raison de croire qu'elle ne fonctionnera pas longtemps dans le futur sans changement, et qui serait rendue impossible ou beaucoup plus difficile par un changement, ce changement ne doit pas arriver. J'espère certainement qu'il n'y a pas d'objection sur ce point (voir le dernier point pour une mise en garde importante que je suis sûr que tout le monde s'empressera de souligner).

2) Évitez d'activer dans un délai qui ne rend pas probable une adoption élevée au niveau des nœuds. Comme pour tous les arguments « nœuds », je noterai que je parle des nœuds « utilisés de manière économique », et non du millier de nœuds espions sur Google Cloud et AWS. Les changements de règles n'ont pas de sens sans que les nœuds ne les appliquent, qu'il s'agisse d'un soft fork, d'un hard fork ou d'un blue fork, donc l'activation dans un délai réduit qui ne permet pas l'adoption de nœuds à grande échelle n'a pas de sens. n'importe quelle valeur et peut provoquer d'autres effets secondaires involontaires.

3) Ne perdez pas (inutilement) de puissance de hachage au profit des mineurs non mis à niveau. Dans la mesure où une partie de la sécurité de Bitcoin provient des mineurs, la réduction de la puissance de hachage du réseau comme effet secondaire d'un changement de règle est une réduction inutile d'un paramètre de sécurité clé du réseau. C'est pourquoi, dans l'histoire récente, les soft forks nécessitaient 95 % de puissance de hachage pour indiquer qu'ils ont été mis à niveau et sont capables d'appliquer les nouvelles règles. De plus, c'est pourquoi les soft forks récents n'ont pas inclus de modifications qui entraîneraient une instance standard de Bitcoin Core à extraire des modifications invalides par de nouvelles règles (en s'appuyant sur le comportement standard de Bitcoin Core).

4) Utilisez l'application de la puissance de hachage pour réduire les risques liés au processus de mise à niveau, dans la mesure du possible. En corollaire de ce qui précède, l’une des principales raisons pour lesquelles nous utilisons des soft forks est que l’application des règles basée sur la puissance de hachage est un moyen élégant d’éviter les divisions du réseau pendant le processus de mise à niveau des nœuds. Même s’il n’est pas logique d’investir de la valeur matérielle dans des systèmes protégés par de nouvelles règles jusqu’à ce qu’une majorité significative de « nœuds économiques » appliquent lesdites règles, la puissance de hachage nous permet de combler parfaitement l’écart de temps entre l’activation et ensuite. En ayant une grande majorité de mineurs appliquant les nouvelles règles, les tentatives de violation des nouvelles règles n'entraînent pas une division significative du réseau, perturbant les utilisateurs existants du système. Si nous ne voulons pas en profiter, nous devrions plutôt faire un hard fork, avec le délai nécessairement lent que cela implique.

5) Suivre la volonté de la communauté, quels que soient les individus ou les objections non motivées, mais sans jamais rejeter toute objection raisonnable. L'histoire récente inclut également une « objection » aux soft forks sous la forme de « c'est mauvais car cela ne résout pas un problème différent que je veux résoudre dès que possible ». Je ne pense pas que quiconque puisse affirmer que cela constitue une objection raisonnable à un changement, et nous devrions être en mesure, en tant que communauté (jamais en tant que développeurs ou simplement un groupe), d'ignorer de telles objections et de progresser malgré eux. Nous ne prenons pas de bonnes décisions techniques en « regroupant » des fonctionnalités non liées pour permettre le jeu politique et le compromis.

Je pense que BIP 9 (plus un softfork bien conçu) coche assez efficacement les cases n°2 à 4 ici, et lorsqu'il est fait soigneusement avec beaucoup d'engagement et de mesure de la communauté, peut également remplir efficacement le n°1. Le numéro 5 est, comme tout le monde le sait, j'en suis sûr, l'endroit où il commence à tomber assez durement.

Le BIP 8 a été proposé comme alternative, en grande partie en réponse aux problèmes du #5. Cependant, un déploiement naïf de celui-ci, de toute évidence, échoue complètement aux numéros 1, 3 et 4, et, à mon avis, échoue également au 5 en donnant à la fois une impression, en créant un précédent, et peut-être même en pratique augmentant la capacité des développeurs à décider des règles de consensus du système. Un déploiement BIP 8 qui mesure plus précisément le soutien de la communauté comme condition préalable pourrait sans doute remplir les objectifs 1 et 5, bien que je ne connaisse aucune proposition concrète sur la manière d'y parvenir. On peut soutenir qu’une fenêtre d’activation beaucoup plus longue pourrait également permettre au BIP 8 de remplir les objectifs 3 et 4, mais uniquement en exploitant les failles « inutilement » et « dans la mesure du possible ».

Vous remarquerez peut-être que, du point de vue de la réalisation des objectifs critiques ici, le BIP 8 n'est différent d'une activation le jour du drapeau que dans le sens où, s'il emprunte le « chemin heureux » d'une activation avant le jour du drapeau, il semble que BIP 9, mais ce n'est pas garanti. Il a en outre la propriété « agréable » que l'activation peut avoir lieu avant le jour du drapeau dans le cas d'une adoption plus rapide par les mineurs, bien qu'il existe une limite à la rapidité avec laquelle elle est utile en raison de l'adoption des nœuds.

Ainsi, pour trouver un équilibre entre les inconvénients de BIP 8 et BIP 9, la proposition du softfork Great Consensus Cleanup a inclus ce texte dans la section de discussion (avec la spécification décrivant un déploiement de BIP 9) :

Malgré certaines suggestions selon lesquelles d'autres méthodes d'activation devraient être utilisées, le BIP 9 est proposé car s'assurer que les mineurs se sont mis à niveau pour appliquer les nouvelles règles est un élément important pour minimiser les perturbations. Alors que les précédents softforks du BIP 9 ont donné lieu à des conflits politiques, ce soft-fork relativement sans importance offre une bonne opportunité de tenter de revenir à l'utilisation du BIP 9 pour assurer la mise à niveau des mineurs avant l'activation, ce que les auteurs considèrent comme un objectif essentiel. Cependant, s'il existe un large accord pour activer ces règles lorsque l'heure d'expiration du BIP 9 est atteinte et que les mineurs n'ont pas encore signalé un niveau de préparation suffisant, une activation ultérieure le jour du drapeau peut être justifiée. Pour cette raison, les mises en œuvre peuvent souhaiter fournir une option de compatibilité qui permet l'application de ces règles le jour du drapeau sans mise à jour.

En fin de compte, malgré des discussions certes plutôt limitées, j'aime toujours ce modèle (même si je ne peux pas le revendiquer comme le mien, la proposition originale est venue de Greg Maxwell). Le BIP 9 ne s’effondre qu’en cas d’objection déraisonnable, qui, naturellement, devrait être très difficile à ignorer, étant donné que nous devons avoir un certain niveau d’accord sur le fait qu’elle est, en fait, déraisonnable (ou non ciblée). Même si j'admets que c'est une possibilité, je la trouve tous deux moins probable que dans les soft-forks précédents, et même si c'est le cas, cela ne fait que ralentir le processus, cela ne l'arrête pas nécessairement. En cas d'échec, le processus BIP 9 offre en fait une bonne opportunité d'apprentissage quant au niveau de préparation et de désir de la communauté pour un changement donné. Bien que nous puissions (et devrions, et sommes) en apprendre beaucoup sur la préparation et l'acceptabilité d'une communauté à un changement grâce à la sensibilisation et à la discussion, il y a quelque chose dans un changement avec un calendrier qui oblige les gens à y réfléchir plus attentivement.

Ainsi, de manière un peu plus concrète, je pense qu’une méthode d’activation qui crée le bon précédent et prend en compte de manière appropriée les objectifs ci-dessus serait :

1) un déploiement standard du BIP 9 avec un horizon temporel d'un an pour l'activation avec 95 % de préparation des mineurs, 2) dans le cas où aucune activation ne se produit dans un délai d'un an, une période de silence de six mois pendant laquelle la communauté peut analyser et discuter des raisons sans activation et, 3) dans le cas où cela aurait du sens, un simple paramètre de ligne de commande/bitcoin.conf qui était pris en charge depuis la version de déploiement d'origine permettrait aux utilisateurs d'opter pour un déploiement BIP 8 avec un délai de 24 mois. horizon pour l’activation du jour du drapeau (ainsi qu’une nouvelle version de Bitcoin Core permettant le drapeau universellement).

Cela fournit un horizon temporel très long pour une activation plus standard, tout en garantissant que les objectifs du n°5 sont atteints, même si, dans ces cas, l'horizon temporel doit être considérablement prolongé pour atteindre les objectifs du n°3. Développer Bitcoin n’est pas une course. Si nous le devons, attendre 42 mois garantit que nous ne créons pas un précédent négatif que nous finirons par regretter à mesure que Bitcoin continue de croître.