Avec les nouvelles versions, les logiciels Bitcoin concurrents élaborent des plans à long terme

Les divisions dans le débat en cours sur la taille des blocs se sont accentuées cette semaine à la suite d'une conférence privée et d'un pic d'activité du réseau qui a vu les utilisateurs attendre plus longtemps et payer plus pour que les transactions soient confirmées.

Le débat en cours sur la manière dont la blockchain Bitcoin devrait être mise à l'échelle pour accueillir de nouveaux utilisateurs aurait été un point central lors de la récenteTable ronde Satoshi, une retraite sur invitation uniquement qui a réuni des développeurs et des chefs d'entreprise. Cependant, des signes suggèrent que les participants sont sortis de l'événement avec unplus négatifvue de l'état du discours.

Mais même si les tensions persistent, le développement des deux versions concurrentes du logiciel Bitcoin – Bitcoin Classic et Bitcoin CORE– se poursuit alors que les groupes font pression pour obtenir le soutien de la base d'utilisateurs plus large du réseau.

Fin février, Bitcoin CORE, le groupe de développeurs le plus important et le plus ancien du réseau, a publié une nouvellefeuille de route, et avec elle, la dernière version – version 0.12.0– du logiciel.

Peu de temps après, l’équipe derrièrel'implémentation alternative du Bitcoin Bitcoin Classic a annoncé sa feuille de route 2016 <a href="https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md">https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md</a> , et a suivi cette semaine avec une sortie de la dernière version de Classic, basée sur la version CORE 0.12.0.

Ces publications restent intéressantes pour la communauté, car lorsqu'il s'agit d'un éventuel fork de Bitcoin , le résultat pourrait être que le gagnant remporte tout.

Les principaux technologues estiment que le groupe capable de parvenir à un consensus autour de sa vision verra rapidement ses règles mises en œuvre, et que malgré les inquiétudes, le risque de voir le réseau se diviser en deux versions incompatibles de la blockchain reste faible.

Le PDG de Bloq, Jeff Garzik, a déclaré à CoinDesk:

« Le réseau Réseaux sociaux rapidement la fourchette gagnante, [il y a] des milliards d'incitations. »

Cet article LOOKS la composition de ces deux versions et la manière dont les deux groupes avancent pour mettre en œuvre leur vision du réseau Bitcoin .

Feuille de route classique

Dans sa feuille de route officielle 2016, l'équipe de développement responsable de Classic a publié le plan prévu pour le déploiement du logiciel au cours des 11 prochains mois.

Au cours de la première phase, l'équipe prévoit de mettre en œuvre le BIP 109, initialement proposé pour CORE par le développeur Gavin Andresen, qui augmenterait la taille des blocs de transactions sur le réseau Bitcoin de 1 mégaoctet (Mo) par bloc actuel à 2 Mo par bloc.

Le seuil de cette transition serait atteint lorsque 751 des 1 000 blocs précédents seraient minés, le code prenant en charge des blocs plus importants. Une fois ce seuil de 75 % atteint, une période d'activation de 28 jours débuterait.

Andresen a déclaré à CoinDesk:

Le danger d'un seuil élevé est qu'un mineur ou un opérateur de pool puisse être contraint d'exercer son veto ; il pourrait être menacé ou victime de chantage. Ce risque n'est pas théorique. Nous constatons des attaques par déni de service contre des pools ou des services qui votent à tort, et des menaces de mort ont même été signalées.

La période de 28 jours a laissé certains membres de la communauté inquiets, mais Andresen a fait remarquer dans un récentarticle de blog que « plusieurs des principaux mineurs de Bitcoin , échanges et fournisseurs de portefeuilles Web » ont indiqué que la période d'activation leur donne « beaucoup de temps » pour modifier leur logiciel.

Il a également défendu la période de grâce de 28 jours en la comparant à la dernière mise à niveau de la version en bloc.

Andresen a expliqué qu'il fallait environ un mois pour atteindre 75 % du taux de hachage et qu'une fois cela fait, il ne fallait que sept jours supplémentaires pour atteindre 95 % du taux de hachage.

En d’autres termes, il estime qu’il ne semble T y avoir de préoccupation majeure concernant une fenêtre de transition de 28 jours.

Phases futures pour Classic

Dans le cas où le hard fork débuterait, Classic entrerait dans sa deuxième phase au cours du deuxième ou du troisième trimestre 2016 avec pour objectif de répondre aux préoccupations concernant la taille des blocs.

« L'objectif de la phase deux est d'éliminer les obstacles techniques (dus à un protocole réseau inefficace) qui limitent la capacité du réseau. Au lieu de transmettre une énorme quantité de données lors de la découverte d'un nouveau bloc, une infime quantité de données sera diffusée, référençant les données de transaction qui ont déjà dû être diffusées », a expliqué Andresen.

Il a poursuivi en déclarant que ces gains d'efficacité ne sont pas un problème pour les blocs de 1 Mo ou 2 Mo, mais que l'objectif ultime de la phase deux était de « mettre fin à la prise de décision centrale sur la « bonne » taille maximale et de revenir à la vision originale de Satoshi d'un système autorégulé ».

La dernière étape pour l'équipe Classic est d'introduire une limite de taille de bloc dynamique, mais seulement après que « les mineurs et les entreprises auront confirmé que la phase deux a résolu avec succès leurs problèmes de taille de bloc ».

Une proposition présentée dans la feuille de route consiste à utiliser une variante du taille de bloc adaptativebasé sur la taille médiane récente des blocs décrite dans un article de blog récent de Stephen Pair, PDG de BitPay.

« Pour déterminer la limite de taille de bloc, vous calculez la taille médiane du bloc sur un échantillon récent de blocs et appliquez un multiple », a écrit Pair.

Pair explique ensuite que, contrairement à la taille moyenne des blocs, la médiane est beaucoup plus difficile à exploiter. Avec une taille de bloc moyenne, les mineurs pourraient gonfler la taille des blocs avec leurs propres transactions ou, au contraire, n'y placer aucune transaction. Avec la médiane, « une action coordonnée de plus de 50 % de la capacité de minage serait nécessaire ».

Bien sûr, si quelqu’un contrôlait plus de 50 % de la capacité minière, Bitcoin aurait des problèmes plus importants à résoudre que la limite de taille des blocs.

Parallèlement à l'augmentation de la taille des blocs, Classic prévoit d'organiser une conférence « où ces solutions et préoccupations de mise à l'échelle et celles à venir pourront être discutées au sein de la communauté ».

La nouvelle version, publiée le 7 mars, intègre des éléments de la version 0.12.0 de Bitcoin Core, mais laisse notamment la fonctionnalité de remplacement par frais (RBF), avec laquelle les utilisateurs peuvent rediffuser des transactions avec des frais plus élevés tant qu'elles n'ont T été incluses dans un bloc, désactivée par défaut.

CORE publie la dernière version du logiciel

Le Équipe de développement CORE a annoncé la sortie de la v0.12.0 le 23 février, que les développeurs ont décrite comme étant potentiellement « la plus ONE à ce jour, avec des améliorations plus significatives que toutes les autres auparavant ».

L'équipe a conçu cette version comme étant axée sur l'optimisation des performances logicielles globales. Dans de nombreux cas, elle visait à réduire les ressources de calcul nécessaires ou à accélérer les actions.

En novembre 2015, le développeur CORE Pieter Wuille a soumis un Request' extractionpour passer à une validation ECDSA basée sur libsecp256k1. Il y expliquait que cette transition présenterait trois avantages.

« La validation de signature est entre 2,5 et 5,5 fois plus rapide ; le code de consensus ne dépend plus d'OpenSSL ou de son analyseur de signature ; supprime le lien avec OpenSSL de libconsensus », a-t-il écrit.

L’abandon d’OpenSSL a également eu des conséquences en termes de sécurité.

« OpenSSL est très complet dans ses capacités, mais cet énorme ensemble de fonctionnalités signifie que sa surface d'attaque est assez grande en conséquence », a écrit l'équipe dans son annonce v.0.12.0.

Après près de trois ans de développement, libsecp256k1 a été fusionné avec le client Bitcoin CORE , ce qui, selon l'équipe, a permis de multiplier par sept la vitesse de validation des signatures. De plus, comme libsecp256k1 est principalement axée sur la validation des signatures, la zone d'exploitation des failles de sécurité est beaucoup plus restreinte, selon CORE.

Poursuivant son optimisation, l’équipe a également déployé un mécanisme pour empêcher les pannes de nœuds dues aux limites du pool de mémoire.

Un autre changement clé concerne la manière dont les nœuds stockent les transactions qui n’ont T encore été intégrées à un nouveau bloc.

Dans un article de blog publié avant luia quitté l'équipe Bitcoin CORE, le développeur Mike Hearn a mis en garde contrele potentielpour une diminution significative des nœuds du réseau.

Au fur et à mesure que les transactions sont effectuées, elles sont stockées dans le pool de mémoire jusqu'à leur affichage sur la blockchain. Plus le nombre de transactions est élevé, plus le nombre de transactions forcées est important. Pour les nœuds disposant de beaucoup de mémoire, ce problème ne se pose T ; en revanche, ceux qui fonctionnent avec une quantité minimale de mémoire risquent de se retrouver dans une situation potentiellement délicate.

Hearn a décrit trois scénarios possibles qui pourraient découler de cette circonstance :

« Le nœud peut devenir incroyablement lent lorsqu'il entre dans l'enfer du swap ; le nœud peut planter lorsqu'il essaie d'allouer de la mémoire et échoue ; le nœud peut être tué par le noyau du système d'exploitation. »

Pour contrer cela, CORE a introduit une fonctionnalité appelée limitation du pool de mémoire, qui définit une limite stricte par défaut sur la taille du pool de mémoire ; plus précisément, elle est définie à 300 Mo dans la version 0.12.0.

En réalité, ce qui se passe, c'est que, lorsqu'un nœud commence à accepter davantage de transactions, si le pool de mémoire atteint cette limite de 300 Mo, le nœud abandonnera d'abord les transactions qui offrent les frais les plus bas par transaction plutôt que de simplement accepter davantage de transactions.

Réduire les coûts des ressources

La version 0.12.0 introduit également un facteur de limitation du trafic montant. Les nœuds relayant constamment les transactions sur le réseau peuvent entraîner une augmentation des ressources de téléchargement, ce qui pèse sur les nœuds individuels.

Un facteur de limitation du trafic de téléchargement permet à l'opérateur de limiter la quantité de données téléchargées et partagées avec le reste du réseau Bitcoin . Si cette limite est atteinte, le nœud servira les blocs demandés au cours de la semaine précédente, minimisant ainsi les besoins en ressources.

Pour éviter davantage que les nœuds ne soient surchargés, l’équipe a introduit l’élagage du portefeuille.

Actuellement, les nœuds stockent une copie complète de la blockchain. Au moment de la rédaction de cet article, cela signifie que chaque nœud doit stocker 57,8 Go de données de transaction. Plus ce volume est important, plus l'espace de stockage requis est important.

Le nouveau « mode élagué » permet à ceux qui utilisent le portefeuille Bitcoin CORE de réduire l'espace disque requis de 60 Go à seulement 2 Go.

« Cela signifie que le nœud se concentrera uniquement sur le suivi des sorties non dépensées et oubliera les blocs précédemment traités ainsi que les sorties qui ont été dépensées », a expliqué l'équipe.

Bien qu'il y ait eu une controverse avec leinclusion du remplacement par des fraisfondamentalement, la nouvelle version s'est concentrée sur le fait de rendre le fonctionnement des nœuds moins gourmand en ressources.

Comme lenombre de nœuds La baisse des ressources nécessaires au réseau a incité davantage d'utilisateurs à utiliser des nœuds validant pleinement la blockchain. Plus le réseau compte de nœuds, plus Bitcoin est sûr.

Image du randonneur perduvia Shutterstock