Les développeurs Bitcoin confrontés à un vieux dilemme : comment mettre à niveau un réseau entier ?

Un vieux débat refait surface dans la communauté des développeurs Bitcoin , soulignant ONEun des défis critiques auxquels sont confrontés les systèmes décentralisés : comment mettre à jour le logiciel lorsque personne n'est apparemment responsable.

Le catalyseur cette fois-ci s'appelle Taproot/Schnorr, une mise à niveau de Politique de confidentialité et de mise à l'échelle qui a duré des années et qui a été vue des progrès passionnants récemment, surtout maintenant que le code sous la forme d'une « pull Request» est en cours de révision et de test, rapprochant de la réalité un changement discuté pour la première fois il y a des années.

Le changement de code lui-même n'est T controversé parmi les développeurs jusqu'à présent. estmettre en discussion est le meilleur moyen d'activer le changement, rendant enfin possible l'envoiBitcoin (BTC) transactions de cette nouvelle manière.

La question fondamentale qui se pose est que Bitcoin n'a pas de leader et est distribué dans le monde entier. Comment l'ensemble du réseau peut-il évoluer en douceur et de manière rétrocompatible, permettant ainsi aux utilisateurs d'anciennes versions du logiciel de continuer à participer ? Quel est le meilleur moyen pour Bitcoin d'opérer ce type de changement sans perturbation ?

Pour être clair : le code de Bitcoin est mis à jour presque tous les jourspar le réseau mondial de développeurs du projet open source. Cependant, les modifications de code « consensuelles », qui touchent une partie plus profonde de Bitcoin, nécessitent un « soft fork », qui requiert à son tour une certaine coordination pour se dérouler sans accroc.

« Il existe une série de conceptions de soft forks qui progressent récemment vers leur mise en œuvre et leur adoption future. Cependant, pour diverses raisons, les méthodes d'activation… ont fait l'objet de peu de discussions. »Bitcoin COREle contributeur Matt Corallo a écrit dansun e-mail à la liste des développeurs de Bitcoin le mois dernier qui a rouvert le débat.

Il existe deux options principales pour mettre en œuvre un soft fork. ONEune d'elles, la Bitcoin Improvement Proposal (BIP) 9, a été utilisée pour quelques soft forks par le passé. Elle garantit mineurssont préparés en amont d'un soft fork, afin de garantir une diffusion fluide du changement sur l'ensemble du réseau. Une objection fréquente à cette approche est qu'elle confère trop de pouvoir aux mineurs.

Il existe également le BIP 8, également connu sous le nom de soft fork activé par l'utilisateur (UASF), qui s'active indépendamment du signalement par les mineurs de leur disponibilité. Selon l'exécution, cette approche pourrait entraîner d'autres problèmes, a averti Corallo.

Leçon d'histoire

Le débat a débuté en 2017, lorsque le BIP 9 a été utilisé pour activer Segregated Witness, ou SegWit, un changement essentiel au grand débat sur la scalabilité de Bitcoin. Pour protéger les mineurs contre l'exploitation de blocs invalides et les pertes financières, SegWit ne s'activait que lorsque 95 % des mineurs signalaient leur disponibilité.

La majorité des pools de minage (groupes de mineurs qui combinent leur puissance de calcul sur le réseau) ont déclaré qu'ils ne soutiendraient pas SegWit – opposant ainsi leur veto – à moins qu'il ne soit associé à une augmentation du paramètre de taille de bloc. (Le mystérieux créateur de Bitcoin avait fixé le plafond à 1 mégaoctet, limitant ainsi le nombre de transactions pouvant être intégrées dans les blocs, publiés toutes les 10 minutes environ.)

Il s'agissait d'une demande controversée qui, selon beaucoup, pouvait conduire à la centralisation du réseau (et qui ne pouvait de toute façon T être exécutée avec succès à moins que Bitcoin ne soit centralisé).

Pour faire court, l'incident a montré que les pools miniers pouvaient utiliser le seuil de 95 % pour extraire d'autres changements au lieu de l'objectif prévu : les aider à s'adapter au changement afin de ne T perdre d'argent.

De nombreux bitcoiners n’ont pas apprécié cette décision, y voyant des mineurs essayant d’utiliser leur pouvoir pour imposer un changement que tous les utilisateurs ne souhaitaient pas.

Alors que le débat faisait rage, un mystérieux développeur connu sous le nom de Shaolinfry a souligné que les bitcoiners pouvaient encore effectuer la mise à niveau. L'idée principale est que les utilisateurs et les plateformes d'échange de Bitcoin devraient décider si une modification devait être appliquée, et que les mineurs Réseaux sociaux leurs désirs, et non l'inverse. Cette méthode avait été utilisée pour activer d'autres modifications de Bitcoin . Shaolinfy a formalisé cette idée dans le BIP 8, également connu sous le nom d'UASF.

De nombreux utilisateurs ont exprimé haut et fort leur soutien à l'UASF SegWit sur les réseaux sociaux et ont commencé à utiliser le logiciel. Cela semble avoir eu l'effet escompté. Avant même l'activation de l'UASF, les mineurs ont commencé à signaler leur soutien à SegWit.

Il est à noter que plusieurs variantes de l'UASF ont circulé durant cette période tumultueuse, ONEune plus prudente (et plus prudente dans son calendrier) et moins controversée que l'autre. Mais sans entrer dans les détails, certains développeurs Bitcoin ont conclu que l'UASF constituait une meilleure solution pour mettre en œuvre les changements.

À l'époque, Rusty Russell, un développeur de la startup Bitcoin Blockstream, est allé jusqu'à s'excuser d'avoir joué un rôle dans la construction du BIP 9.

« Je ne m'attendais T à ce que ce point de contrôle soit utilisé comme point d'étranglement pour rançonner le réseau. Cela modifie considérablement le modèle de risque ;BIP-8« Il s'agit désormais d'une méthode bien supérieure pour les mises à niveau du réseau, où les mineurs peuvent seulement accélérer le processus, et non le bloquer », a-t-il écrit dans un article de Medium.poste.

De longs souvenirs

En se souvenant de tout ce drame, certains développeurs hésitent à utiliser à nouveau BIP 9 pour Schnorr/Taproot ou d'autres changements futurs.

« Je pense que le BIP 9 est un échec avéré »,dit Bitcoin CORE Le développeur Luke Dashjr, répondant à Corallo, a ensuite fourni les raisons techniques de son objection. Lors du débat sur la mise à l'échelle, Dashjr a été ONEun des plus fervents défenseurs d'un UASF pour faire adopter SegWit.

Alex Bosworth, développeur chez Lightning Labs, a exprimé une Analyses similaire, basée en partie sur le récent drame entourant Bitcoin Cash (BCH), une Cryptomonnaie plus petite qui s'est séparée du Bitcoin en 2017.

Un groupe important de pools miniers de Bitcoin Cash a récemmentproposéqu'une partie du BCH de chaque nouveau bloc devrait être versée à un fonds de développement, ce que Bosworth considère comme un autre exemple de pools miniers qui font jouer leurs muscles d'une manière qui est mauvaise pour la décentralisation des Cryptomonnaie .

Je sais que l'idée courante pour le déploiement d'un soft fork est d'essayer la méthode traditionnelle du mineur amical. Mais un bon ONE de notre taux de hachage actuel s'est organisé en cartel à des fins de censure pour voler les subventions aux cryptomonnaies. tweetéBosworth, qui travaille sur l'infrastructure du réseau Lightning rapide et évolutif.

C’est pourquoi il soutient une méthode UASF, bien ONE un horizon temporel plus long.

« Un UASF à combustion lente me semble le plus approprié », a-t-il ajouté.

Synthèse

Mais certains, appelant à la prudence, craignent que le fait de considérer les UASF comme seule méthode d'activation puisse ouvrir la possibilité d'imposer des changements qui pourraient nuire au Bitcoin.

Par exemple, ONEune des raisons pour lesquelles les développeurs ont initialement apprécié BIP 9 est que le seuil de 95 % pouvait constituer une sorte de filet de sécurité. Si un problème survenait pendant que les pools de minage travaillaient à la mise à niveau de leur logiciel, ils pouvaient alors bloquer la modification. Il est plus difficile d'arrêter une activation UASF une fois lancée.

C'est pourquoi Corallo a réédité une vieille idée, un mélange de BIP 8 et de BIP 9. Le soft fork débuterait avec BIP 9. Ensuite, en cas d'échec au cours d'une année en raison d'« objections déraisonnables », les utilisateurs pourraient débattre et se regrouper pendant six mois. Ensuite, si le changement est vraiment souhaité par la communauté, ils pourraient essayer BIP 8 pendant une année supplémentaire.

Certains développeurs pourraient arguer que ce délai est trop long pour un changement sans « objections déraisonnables ». Mais Corallo a appelé à la patience.

Déterminer si les objections sont réellement « déraisonnables » pourrait prendre du temps. « En cas d'échec, le processus BIP 9 offre en réalité une bonne occasion d'évaluer le niveau de préparation et d'adhésion de la communauté à un changement donné », a-t-il déclaré.

« Développer Bitcoin n'est pas une course. Si nous devons le faire, attendre 42 mois nous évitera de créer un précédent négatif que nous regretterons à mesure que Bitcoin continuera de croître », a-t-il déclaré. Les lecteurs peuvent lire l'intégralité du raisonnement de Corallo ainsi que les nombreuses réponses nuancées des développeurs. ici.

Et alors que Russell semblait assez opposé au BIP 9 en 2017, il a déclaré à CoinDesk qu'il était désormais d'accord avec cette approche hybride.

« Étant donné que la tentative des mineurs de bloquer les modifications n'a T fonctionné et que nous T trop souffert du retard, l'activation de BIP-9 ne me dérange T », a-t-il déclaré. Il a toutefois proposé un délai plus court que celui de Corallo.

« Le délai d'expiration d'un an du BIP-9 est peut-être trop long, et une expiration de six mois serait préférable. Ainsi, les utilisateurs peuvent organiser un UASF si l'activation du BIP-9 échoue et qu'ils estiment que cela est dû à l'obstruction des mineurs », a déclaré Russell.

Les ingénieurs examinent minutieusement le code Taproot/Schnorr proposé afin de corriger les problèmes persistants. Les développeurs ont donc encore le temps de discuter des options d'activation. Mais la communauté devra se prononcer avant que cette modification puisse être appliquée à Bitcoin, renforçant ainsi la Politique de confidentialité du réseau.