Proposition de mise à l'échelle « Segwit2x » de Bitcoin : les développeurs CORE adoptent une position critique

Quelques jours après le dévoilement d'une proposition largement soutenue mais controversée visant à augmenter la capacité de transaction du Bitcoin, les détails techniques du plan sont révélés.

Cela n'est peut-être pas particulièrement surprenant si vous êtes très familier avec le débat de longue date sur la taille des blocs de Bitcoin, mais le code provisoire de ce qui est maintenantconnu sous le nom de « Segwitx2 »n'a T été particulièrement bien accueilli par la communauté des développeurs open source du projet.

Un soi-disant Request' extractionPar exemple, la réponse de Jeff Garzik, cofondateur de Bloq, a suscité une avalanche de commentaires sceptiques. La plupart étaient plutôt techniques, émanant de développeurs travaillant sur Bitcoin depuis longtemps, mais la réponse semblait se résumer à ceci : « Pourquoi le groupe n'utilise- T une méthode plus sûre, ONE que beaucoup d'entre nous ont suggérée plus tôt ? »

Certains commentaires semblaient moqueurs. « Cette pull Request est assez étrange », a déclaré Udi Wertheimer, responsable de la recherche blockchain chez Colu, dans sa réponse.

« Il n’y a toujours pas de tests », a simplement déclaré un autre développeur.

Néanmoins, Garzik, un ancien développeur de Bitcoin CORE employé par le processeur Bitcoin BitPay, a accueilli favorablement les commentaires et, plus tard dans la journée, il a répondu sur Moyen. "C'était unpoint de départ", a-t-il déclaré, indiquant sa position selon laquelle la mise en œuvre actuelle sur GitHub est censée être un travail en cours.

Garzik a ajouté qu'il était d'accord avec les commentaires reçus et qu'il approuvait les modifications qui permettraient au code d'être compatible avec la version existante de Segregated Witness (ou SegWit) - un plan visant à faire évoluer la blockchainproposé par La rédaction de Bitcoin COREen 2015.

« Si le résultat maximise encore davantage la compatibilité et réutilise davantage les tests existants, ce sera une WIN. Un progrès en avant », a écrit Garzik.

Peurs de la fourchette

Pourtant, malgré toute la dérision implicite, ce débat entre développeurs pourrait être considéré comme un exemple de « collaboration » et d’évaluation par les pairs.

Il convient probablement de noter qu'aucun des développeurs bénévoles derrière Bitcoin CORE n'a signé le «accord« Sur la proposition, initialement annoncée par la société de portefeuille d'investissement DCG la semaine dernière. Comme l'indiquent les inquiétudes ci-dessus, cela s'explique en partie par des problèmes techniques, et en partie par le fait que certains ne croient T qu'un hard fork soit nécessaire pour le moment. »

Certains affirment que les augmentations de capacité au-delà de SegWit peuvent être réalisées par d'autres moyens rétrocompatibles qui ne risquent T d'exclure certains participants du réseau du système.

Une fois la proposition publiée, et même bien avant, les développeurs avaient donné leur avis technique surquelle est la meilleure façon de déployer un hard fork, ce qui pourrait expliquer une pointe d’amertume de la part des développeurs lors des discussions récentes.

Mais même si beaucoup d’entre eux ne sont T enthousiastes à l’idée de connaître les détails de la proposition, cela n’a T empêché jusqu’à présent les développeurs d’essayer d’améliorer la mise en œuvre.

« J'ai écrit BIP91 pour essayer de rendre la proposition plus sensée », a déclaré le développeur de Bitcoin James Hilliard, ajoutant qu'à ses yeux, le calendrier actuel du hard fork est « complètement irréaliste ».

D'autres accordent plus de poids à la proposition, qui bénéficie du soutien de plus de 60 entreprises et de plus de 80 % des opérateurs et entreprises de pools miniers de bitcoins.

« Je pense que nous devrions nous appuyer sur cette proposition et l'améliorer », a déclaré Adam Back, PDG de Blockstream. Dans l'ensemble, ce dernier s'est révélé être ONEune des voix les plus positives, certains commentaires suggérant que la résistance des développeurs pourrait engendrer des problèmes de perception.

En particulier, il essaie d'orienter l'intérêt vers une proposition appelée « spoonnet », une branche derecherche sur les hard forks du contributeur de Bitcoin CORE, Johnson Lau.

Eric Lombrozo, contributeur de Bitcoin CORE et auteur du code SegWit, partageait une vision collaborative similaire. « Je travaillerai dur avec [Barry Silbert, fondateur et PDG de DCG] pour faire de ce projet un succès », a-t-il déclaré. a écritsur les réseaux sociaux, non sans quelques réserves.

Trop, trop tôt ?

En fin de compte, de nombreux développeurs ne pensent T que la proposition soit ONE.

Bryan Bishop, contributeur de Bitcoin CORE, a résumé les préoccupations de la manière la plus succincte :

Je pense qu'à terme, le hard fork [DCG] ne parviendra pas à assurer la transition sécurisée de l'ensemble du réseau. Il n'y a aucune protection contre la rediffusion. Le délai est excessivement court. Il ne tire T parti des recherches antérieures sur le hard fork.

« Je pense que l'ensemble du secteur doit prendre conscience du temps que prennent ces processus », a-t-il ajouté, arguant que l'évaluation par les pairs et les tests sont longs. (D'autres développeurs et utilisateurs de Bitcoin ont également remis en question ce délai de six mois.)

La question la plus importante est peut-être la suivante : si le groupe répond à ces préoccupations techniques, davantage de développeurs le soutiendront-ils ?

La réponse, comme d’habitude, a été compliquée et mitigée, certains exprimant le désir de prendre en compte tous les compromis.

« Les développeurs de Bitcoin CORE estiment généralement qu'une capacité considérable peut être gagnée grâce aux soft forks et aux mises à niveau rétrocompatibles. Je ne pense T que les développeurs de Bitcoin CORE se Rally à un hard fork dans un avenir NEAR , surtout pas ONE par une réunion Secret à huis clos », a déclaré Bishop.

Le développeur Jonas Schnelli, connu pour la bibliothèque libbtc, a déclaré qu'il pourrait éventuellement soutenir un hard fork pour une augmentation de la taille des blocs si on lui donnait plus de temps.

« Je serais satisfait de SegWit2x s'il pouvait être réduit à 80 % sans être incompatible avec l'implémentation [SegWit] existante », a déclaré Schnelli. « Et faire le [hard fork] plus tard. »

D'autres ne pensent tout simplement T que cela fonctionnera, semblant le traiter avec le même intérêt qu'ils l'ont traité. Bitcoin XT ou Bitcoin Classic – d’autres propositions de hard fork qui ont échoué (bien que ce nouvel effort ait recueilli davantage de soutien).

Autres options

De nombreux développeurs ont exprimé le sentiment que la capacité de transaction pourrait être augmentée par d'autres moyens, peut-être plus sûrs. D' une ONE, certains ont tendance à penser que SegWit constitue une meilleure solution en soi, sans le hard fork qui l'accompagne, susceptible d'entraîner une division du réseau.

« Sur SegWit2x, il n'y a aucune raison technique de coupler [Segwit] à un [hard fork]. Seulement une raison politique. Et Bitcoin a été créé pour se tenir à l'écart de la politique… c'est pourquoi je ne le soutiens pas », a déclaré Schnelli.

Luke Dashjr, contributeur de Bitcoin CORE, était ouvert à une autre proposition récente, appelée COOPÉRATIVE, qui regroupe de nombreuses recherches sur les hard forks en une ONE proposition d'amélioration du Bitcoin (BIP), pour un déploiement plus sûr. Cependant, il émettait des réserves quant à l'augmentation aussi rapide de la taille des blocs.

Dashjr a activement promu BIP148, un mécanisme controversé rétrocompatible qui a étéprendre de l'ampleuret cela a également une date limite d'activation, bien que certains craignent que cela puisse également entraîner une rupture de chaîne.

Il a conclu :

« Quoi qu’il en soit, le BIP148 commence en août. »

Déclaration de transparence: CoinDesk est une filiale de Digital Currency Group (DCG).

Homme sur une échelle de chantierimage via Shutterstock