Bitcoin Core : : Bitcoin Core 0.12.0 est sorti !


12.0. Beaucoup de travail acharné a été consacré à cette version et il se peut qu’elle soit la plus importante à ce jour, avec des améliorations plus importantes que toutes les autres auparavant.

Voici les principales améliorations dont vous bénéficierez si vous mettez à niveau vos nœuds vers la version 0.12  :

  • Validation de signature 7 fois plus rapide
  • Possibilité de limiter le trafic de téléchargement
  • Prévention des collisions via les limites du pool de mémoire
  • Possibilité d’envoyer des transactions pouvant être majorées de frais
  • Utilisation automatique de Tor lorsqu’il est en cours d’exécution
  • Possibilité pour les applications de s’abonner aux notifications avec ZeroMQ
  • Utilisation massivement réduite du disque pour les portefeuilles
  • Assemblage de blocs beaucoup plus rapide pour les mineurs
  • En plus de celles-ci, il y a 13 autres améliorations qui ne figuraient pas en tête de liste mais qui sont néanmoins très utiles. Vous pouvez en trouver une liste complète à la fin de cet article.

    Bitcoin Core : : Bitcoin Core 0.12.0 est sorti !

    Maintenant, allons plonger plus profondément dans chacune de ces améliorations.

    Validation de signature 7 fois plus rapide

    Dans Bitcoin Core, OpenSSL était traditionnellement utilisé pour valider les signatures ECDSA dans les transactions Bitcoin. OpenSSL est très complet dans ses capacités (fait bien plus que simplement valider les signatures ECDSA), mais cet énorme ensemble de fonctionnalités signifie que sa surface d’attaque est par conséquent assez grande. En raison de la menace que cela représente pour la sécurité de Bitcoin, il est devenu une priorité de dissocier OpenSSL de Bitcoin Core et de le remplacer par une alternative plus simple et plus ciblée.

    Pour résoudre ce problème, une nouvelle bibliothèque de validation de signature ECDSA appelée libsecp256k1 a été développée par des membres de l’équipe Bitcoin Core et branchée en remplacement d’OpenSSL. C’est le résultat de près de 3 ans d’ingénierie complexe, et avec cette intégration, la surface d’attaque pour le code de validation de signature a été considérablement réduite.

    De plus, la validation de signature de libsecp256k1 est beaucoup plus rapide que celle effectuée par OpenSSL. Il est jusqu’à 7 fois plus rapide sur une architecture 64 bits, et la réindexation brute et la validation des blocs prennent désormais moins de la moitié du temps qu’auparavant – une avancée majeure pour la validation des transactions Bitcoin.

    Pieter Wuille, Greg Maxwell et Cory Fields

    Possibilité de limiter le trafic de téléchargement

    Le trafic de téléchargement de nœuds peut être fastidieux pour certains utilisateurs, de sorte que la possibilité de limiter ce trafic est une amélioration indispensable. Les utilisateurs de nœuds ont désormais la possibilité de définir des limites souples sur la quantité de données qu’ils téléchargent et servent à leurs pairs. Les utilisateurs peuvent définir un paramètre qui spécifie la quantité de données que le nœud doit cibler pour être servi quotidiennement. Il essaiera de rester en dessous de la limite, plutôt que de l’atteindre, et s’il atteint la limite, il ne servira que les blocs demandés au cours de la semaine dernière.

    Jonas Schnelli

    Prévention des collisions via les limites du pool de mémoire

    Les anciennes versions de Bitcoin Software n’avaient aucune limite sur le nombre de transactions qu’elles autoriseraient dans leur pool de mémoire. Même si les nœuds n’accepteront que les transactions qui ont un certain frais de relais minimum spécifié, parfois le nombre de transactions qui répondent à ces exigences deviendra arbitrairement élevé et provoquera le crash des nœuds avec une RAM relativement faible. Ce qui est particulièrement préoccupant, c’est que les attaquants peuvent profiter de ce système en inondant le réseau de transactions afin de planter un sous-ensemble de nœuds.

    Avec cette mise à jour, les nœuds ont désormais des limitations par défaut sur la taille de leurs pools de mémoire et l’opérateur peut le configurer en fonction de la quantité de mémoire qu’il souhaite dédier au mempool. Lorsque la limite de mémoire est atteinte, de nouvelles transactions peuvent toujours être acceptées, tandis que les transactions avec les frais les plus bas seront supprimées du mempool. Cette nouvelle limitation de mémoire garantit que les plantages inattendus ne se produiront pas en raison du nombre de transactions mises en cache qui deviennent incontrôlables.

    Matt Corallo et Suhas Daftuar

    Possibilité d’envoyer des transactions pouvant être majorées de frais

    Les transactions sont souvent bloquées si elles ont des frais trop bas. Cela peut causer des problèmes car les sorties de transactions non dépensées (UTXO) qui ont été utilisées dans ces transactions peuvent être difficiles à dépenser, gelant potentiellement les fonds. Les frais de transaction appropriés sont difficiles à calculer car ils dépendent fortement du volume des transactions et de leurs frais à un moment donné. Ainsi, on sous-estime généralement, ce qui entraîne de nombreuses transactions bloquées, ou on surestime, ce qui entraîne un trop-payé massif et une perte constante de fonds.

    Une nouvelle fonctionnalité appelée Opt-in Replace-by-Fee donne aux expéditeurs de transactions la possibilité de configurer leurs transactions pour pouvoir être remplacées ultérieurement par d’autres transactions qui spécifient des frais plus élevés. Les expéditeurs peuvent commencer avec des frais peu élevés et voir si leur transaction est acceptée, et sinon ils peuvent augmenter leurs frais jusqu’à ce qu’elle soit acceptée. Cela permet aux expéditeurs de minimiser les frais qu’ils paient et de maximiser les chances que leurs transactions soient incluses dans un bloc.

    Peter Todd et Suhas Daftuar

    Utilisation automatique de Tor lorsqu’il est en cours d’exécution

    Les nœuds détecteront désormais si Tor est en cours d’exécution et, si c’est le cas, ils créeront automatiquement des services cachés Tor et se connecteront à d’autres nœuds via le réseau Tor. Aucune configuration manuelle n’est requise.

    Wladimir van der Laan

    Possibilité pour les applications de s’abonner aux notifications avec ZeroMQ

    Jusqu’à présent, la prise en charge des services externes pour s’abonner aux notifications concernant l’arrivée de nouveaux blocs et les transactions entrantes était limitée. Les services ont désormais cette capacité grâce à une intégration avec ZeroMQ.

    Johnathan Corgan

    Utilisation massivement réduite du disque pour les portefeuilles

    Les utilisateurs du portefeuille Bitcoin Core ressentent souvent le fardeau des exigences élevées en matière de stockage de données qui accompagnent l’exécution d’un nœud complet (qui atteint désormais 60 Go et continue d’augmenter). Pour les utilisateurs dont la capacité de stockage est limitée et qui souhaitent toujours utiliser un portefeuille avec un nœud complet, ils ont désormais la possibilité d’exécuter leur portefeuille en mode élagué. 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. Cela signifie à son tour que les utilisateurs pourront exécuter un nœud complet tout en ne stockant qu’environ 2 Go de données, une réduction massive par rapport aux 60 Go précédemment requis.

    Jonas Schnelli, Greg Maxwell et Adam Weiss

    Assemblage de blocs beaucoup plus rapide pour les mineurs

    Traditionnellement, la création de modèles de blocs était assez coûteuse pour les mineurs, nécessitant des temps de calcul élevés et pas mal de mémoire. Le temps de calcul élevé est une conséquence du fait qu’historiquement, les mineurs ont dû effectuer des calculs critiques consensuels pour la validation des blocs simultanément pendant qu’ils assemblent un bloc. Les besoins élevés en mémoire étaient dus au fait qu’historiquement, lors de l’assemblage de blocs, chaque transaction dans son pool de mémoire devait avoir ses entrées extraites dans un cache en mémoire pour divers calculs.

    Avec la version 0.12, les calculs critiques pour le consensus concernant les transactions individuelles ne sont plus effectués en même temps lors de l’assemblage des blocs, mais sont pré-calculés sur toutes les transactions dès qu’elles atteignent le pool de mémoire, puis mises en cache. Cela signifie que lors de l’assemblage du bloc, la plupart des calculs ont déjà été effectués et le modèle de bloc peut être créé extrêmement rapidement. Plus précisément, cela représente une réduction de temps d’un intervalle mesuré en secondes à un intervalle mesuré en dizaines de millisecondes.

    Les pré-calculs effectués signifient également que les entrées de toutes les transactions dans son pool de mémoire ne doivent plus être tirées dans le cache en une seule fois, ce qui entraîne une réduction considérable des besoins en mémoire.

    Alex Morcos

    Mot de clôture

    La sortie de la version 0.12 sera une avancée majeure pour le client Bitcoin Core. Cependant. Pour plus de détails.md.

    ///bin/bitcoin-core-0.12.0/.

    L’équipe de développement de base de Bitcoin

    v0.

    Résumés des réunions hebdomadaires

    Communauté IRC.

    Twitter  :

    Ce billet de blog a été écrit par Ryan Shea sur la base des notes de publication officielles.