Les développeurs de Bitcoin Core ont déplacé la version 32.0 vers les tests de version candidate, le logiciel stable étant prévu pour une éventuelle version le 10 octobre après des semaines de vérifications publiques.
Bitcoin Core 32 vise une version le 10 octobre
Le calendrier de sortie officiel de Bitcoin Core montre que les développeurs ont créé la branche version 32 et ont commencé le cycle de publication-candidat le 14 septembre. Le premier candidat, connu sous le nom de v32.0rc1, est maintenant disponible pour les tests avant que les développeurs ne décident de marquer ou non la version stable.
Le projet a fixé au 10 octobre la date prévue pour la version 32.0, bien que le calendrier la décrit comme un objectif plutôt que comme une date limite confirmée. Les problèmes détectés lors des tests des candidats pourraient nécessiter des versions supplémentaires et retarder la version finale.
Les préparatifs ont commencé des mois plus tôt. Les développeurs ont ouvert les traductions et introduit un gel progressif des modifications de traduction le 6 août, suivi d’un gel des fonctionnalités le 20 août. À partir de cette date, la branche version 32 a accepté les corrections de bugs mais aucune nouvelle fonctionnalité avant les tests finaux.
Lorsque la branche s’est séparée de la base de code principale le 14 septembre, le développement de Bitcoin Core 33 a également commencé sur la branche principale. La scission permet aux contributeurs de tester et de réparer la prochaine version sans arrêter de travailler sur la version suivante.
Les versions candidates donnent aux opérateurs de nœuds, aux développeurs de portefeuilles et aux autres utilisateurs le temps de trouver des bogues dans différentes conditions matérielles et logicielles. Le processus de test de Bitcoin Core couvre des fonctions telles que la validation de bloc, la communication peer-to-peer, les opérations de portefeuille et les appels de procédure à distance utilisés par les applications connectées à un nœud.
Les lectures parallèles de la base de données accélèrent les vérifications des blocs
L’un des principaux changements de performances permet à Bitcoin Core de lire les données de sa base de données en parallèle tout en vérifiant les blocs. La méthode peut raccourcir le temps de validation car le logiciel n’a plus besoin de compléter chaque base de données pertinente lue l’une après l’autre.
Une validation plus rapide ne signifie pas que Bitcoin produira des blocs plus rapidement. Les mineurs sont toujours en compétition pour ajouter des blocs selon les règles de preuve de travail de Bitcoin, qui visent un intervalle moyen d’environ 10 minutes. La version 32 modifie la façon dont un nœud traite les informations requises plutôt que le calendrier d’émission ou le timing des blocs du réseau.
La distinction est importante car Bitcoin Core est un logiciel de nœud et non une mise à jour gérée de manière centralisée du réseau Bitcoin. Les opérateurs décident quelle version installer et la version ne remplace pas automatiquement le logiciel exécuté sur chaque nœud.
La version 32 n’introduit pas non plus de nouvelle règle de consensus et ne nécessite pas de soft fork. Son processus de publication diffère des changements de protocole qui nécessitent une coordination entre les mineurs, les opérateurs de nœuds et les autres participants du réseau.
Comme précédemment rapporté par crypto.news, Paul Sztorc, PDG de LayerTwo Labs, a déclaré que chaque soft fork Bitcoin proposé depuis Taproot n’avait pas réussi à s’activer. BIP-110, une proposition contestée liée à la politique de relais de transactions, a reçu un soutien de 2,53 % des mineurs avant que sa branche d’application ne s’arrête après deux blocs.
Bitcoin Core 32 peut donc améliorer les performances du logiciel sans dépendre du processus d’activation requis pour un changement consensuel. Les opérateurs de nœuds restent libres de tester le candidat, de continuer à utiliser une ancienne version ou d’installer la version stable après publication.
Les commandes de portefeuille adoptent le nouveau format PSBT
Les fonctions de portefeuille représentent un autre ensemble de modifications dans la version 32. Quatre commandes créeront par défaut des transactions Bitcoin partiellement signées à l’aide de la version 2 du PSBT, selon les détails partagés par Bitcoin News.
Un PSBT permet à des portefeuilles, des appareils ou des participants distincts d’échanger les informations nécessaires pour créer et signer une transaction Bitcoin sans exposer les clés privées. Le format est couramment utilisé avec les portefeuilles matériels, les configurations de signature hors ligne et les transactions nécessitant plusieurs signatures.
La version 2 de PSBT modifie la façon dont les informations sur les transactions sont organisées et permet aux participants de mettre à jour des parties d’une transaction sans créer au préalable une transaction complète non signée. L’ancien format PSBT restera disponible lorsque les utilisateurs ou les applications connectées en auront besoin.
Conserver les deux versions réduit le risque de casser brusquement les portefeuilles et les services qui n’ont pas adopté le nouveau format. Les développeurs intégrant Bitcoin Core à d’autres logiciels devront toujours vérifier si leurs systèmes s’attendent à la valeur par défaut précédente.
Pour les détenteurs individuels, le changement ne modifie pas les soldes Bitcoin, les clés privées ou les règles régissant les transactions valides. Son effet pratique concerne les flux de travail du portefeuille et les applications qui appellent les commandes concernées.
Les correctifs de sécurité réduisent les risques liés aux commandes et à la mémoire
La version 32 inclut également un correctif pour les noms de portefeuille personnalisés qui pourraient entraîner l’exécution de commandes sur des nœuds non Windows. Le problème concernait la manière dont les noms spécialement construits interagissaient avec l’exécution des commandes, plutôt qu’une modification de la cryptographie sous-jacente de Bitcoin.
Un correctif distinct corrige la croissance de la mémoire causée par une activité HTTP non authentifiée. Dans un test cité par Bitcoin News, l’utilisation de la mémoire a atteint environ 3,2 Go avant le correctif, contre environ 3 Mo après que les développeurs ont appliqué le changement.
Les interfaces distantes permettent à d’autres programmes de communiquer avec Bitcoin Core, ce qui rend les contrôles de mémoire pertinents pour les opérateurs qui exposent les services de nœuds aux applications connectées. Les paramètres d’accès, les pare-feu et l’authentification restent des éléments distincts de la sécurisation d’un déploiement.
Pour les utilisateurs américains, le candidat est le plus pertinent pour les opérateurs de nœuds, les fournisseurs de portefeuilles, les bourses, les mineurs et les sociétés d’infrastructure qui exécutent Bitcoin Core dans leurs systèmes. Cette publication ne modifie pas le traitement par la SEC des produits négociés en bourse au comptant Bitcoin, les règles fiscales des investisseurs ou le statut juridique du BTC.
Les sociétés financières américaines ont également accru leur soutien au travail de sécurité open source de Bitcoin. En juillet, Anchorage Digital, ARK Invest, BlackRock, Block, Blockstream, Coinbase, Fidelity Digital Assets, Galaxy et Strategy ont formé le Bitcoin Security Consortium avec 15 millions de dollars de promesses de don sur trois ans.
Selon l’annonce du consortium, chaque membre dirigera son financement de manière indépendante plutôt que de placer l’argent dans un pool partagé. Le groupe a déclaré qu’il ne contrôlerait pas le développement de Bitcoin, ne prendrait pas position sur des propositions de protocole spécifiques ni ne parlerait au nom des contributeurs du projet.
Mike Schmidt, directeur exécutif de Brink, une organisation à but non lucratif qui finance les développeurs Bitcoin, coordonne le travail quotidien du consortium en tant que bénévole. Son objectif initial est la recherche sur les problèmes de sécurité à long terme, y compris les protections contre les futurs risques liés à l’informatique quantique.
