Les développeurs de Bitcoin Core ont fait passer la version 32.0 en phase de test de candidat à la publication, le logiciel stable étant prévu pour une sortie possible le 10 octobre après des semaines de vérifications publiques.
Résumé
- Bitcoin Core 32 est entré en phase de test de candidat à la publication le 14 septembre après un gel des fonctionnalités en août.
- Les lectures parallèles de la base de données pourraient réduire les temps de validation des blocs sans modifier le rythme de production des blocs de Bitcoin.
- Quatre commandes de portefeuille utiliseront PSBT version 2 par défaut tout en conservant l'ancien format.
- Des correctifs de sécurité traitent les noms de portefeuille non sécurisés et les requêtes HTTP non authentifiées qui causaient une utilisation intensive de la mémoire.
Bitcoin Core 32 vise une sortie le 10 octobre
Le calendrier de publication officiel de Bitcoin Core montre que les développeurs ont créé la branche de la version 32 et ont commencé le cycle de candidats à la publication le 14 septembre. Le premier candidat, connu sous le nom de v32.0rc1, est désormais disponible pour les tests avant que les développeurs ne décident d'étiqueter la version stable.
Le projet a fixé le 10 octobre comme date prévue pour la version 32.0, bien que le calendrier la décrive comme un objectif plutôt qu'une échéance confirmée. Les problèmes découverts lors des tests des candidats pourraient nécessiter des publications 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 partiel 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 de la version 32 a accepté des corrections de bogues 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 séparation permet aux contributeurs de tester et de réparer la prochaine version sans interrompre le travail sur la version suivante.
Les candidats à la publication 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 des blocs, la communication pair à pair, les opérations de portefeuille et les appels de procédure distante utilisés par les applications connectées à un nœud.
Les lectures parallèles de la base de données accélèrent la vérification des blocs
L'un des principaux changements de performance permet à Bitcoin Core de lire les données de sa base de données en parallèle lors de la vérification des blocs. Cette méthode peut raccourcir le temps de validation car le logiciel n'a plus à effectuer chaque lecture pertinente de la base de données l'une après l'autre.
Une validation plus rapide ne signifie pas que Bitcoin produira des blocs plus rapidement. Les mineurs continuent de rivaliser 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 la cadence des blocs du réseau.
Cette 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 publication 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 ni n'exige 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, le PDG de LayerTwo Labs, Paul Sztorc, a déclaré que chaque proposition de soft fork de Bitcoin depuis Taproot n'a pas réussi à s'activer. Le BIP-110, une proposition contestée liée à la politique de relais des transactions, a reçu 2,53 % de soutien des mineurs avant que sa branche d'application ne cale 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 de consensus. Les opérateurs de nœuds restent libres de tester le candidat, de continuer à utiliser une version plus ancienne ou d'installer la version stable après sa publication.
Les commandes de portefeuille adoptent le nouveau format PSBT
Les fonctions de portefeuille représentent un autre ensemble de changements dans la version 32. Quatre commandes créeront des transactions Bitcoin partiellement signées en utilisant PSBT version 2 par défaut, selon les détails partagés par Bitcoin News.
Un PSBT permet à des portefeuilles, appareils ou participants distincts d'échanger les informations nécessaires pour construire 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 plus d'une signature.
La version 2 de PSBT modifie la façon dont les informations de transaction sont organisées et permet aux participants de mettre à jour des parties d'une transaction sans d'abord créer une transaction non signée complète. 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 rupture brutale des portefeuilles et des services qui n'ont pas adopté le nouveau format. Les développeurs intégrant Bitcoin Core avec d'autres logiciels devront encore vérifier si leurs systèmes s'attendent à l'ancien paramètre par défaut.
Pour les détenteurs individuels, ce changement ne modifie pas les soldes en Bitcoin, les clés privées ni les règles régissant les transactions valides. Son effet pratique concerne les flux de travail des portefeuilles 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 portefeuilles personnalisés qui pouvaient entraîner l'exécution de commandes sur des nœuds non Windows. Le problème concernait la manière dont des noms spécialement construits interagissaient avec l'exécution des commandes, plutôt qu'un changement de la cryptographie sous-jacente de Bitcoin.
Un correctif distinct traite 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 atteignait environ 3,2 gigaoctets avant le correctif, contre environ 3 mégaoctets après que les développeurs ont appliqué la modification.
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œud à des 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 concerne surtout les opérateurs de nœuds, les fournisseurs de portefeuilles, les bourses, les mineurs et les entreprises d'infrastructure qui exécutent Bitcoin Core dans leurs systèmes. La version ne modifie pas le traitement par la SEC des produits négociés en bourse au comptant sur Bitcoin, les règles fiscales des investisseurs ni le statut juridique du BTC.
Les entreprises 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 sur trois ans.
Selon l'annonce du consortium, chaque membre dirigera son financement indépendamment plutôt que de placer l'argent dans un pool commun. Le groupe a déclaré qu'il ne contrôlera pas le développement de Bitcoin, ne prendra pas position sur des propositions de protocole spécifiques et ne parlera pas au nom des contributeurs du projet.
Mike Schmidt, directeur exécutif de l'organisation à but non lucratif de financement des développeurs Bitcoin Brink, coordonne le travail quotidien du consortium à titre bénévole. Son objectif initial est la recherche sur les problèmes de sécurité à long terme, y compris les protections contre les risques futurs liés à l'informatique quantique.
