Les portefeuilles Bitcoin populaires risquent de perdre le support pour de nouveaux appareils matériels alors qu'un pont de sécurité critique cesse d'accepter de nouveaux dispositifs

Bitcoin HWI, une interface largement utilisée pour connecter les logiciels de portefeuille aux dispositifs de signature matériels, se dirige vers la retraite, tandis que le projet Rust que son mainteneur a cité comme un successeur prometteur n'a pas encore démontré un transfert de production.

Le mainteneur de l'Interface de Portefeuille Matériel de Bitcoin Core, ou HWI, a déclaré le 18 août que le projet était effectivement en mode maintenance depuis des années et avait largement été un effort solitaire. HWI n'acceptera plus de nouveaux dispositifs ou fonctionnalités au-delà des travaux nécessaires pour MuSig2. Une fois ce travail terminé, le mainteneur s'attend à faire une publication qui sera probablement la dernière du projet, puis à maintenir HWI en mode minimal jusqu'à ce qu'un remplacement adéquat soit prêt.

HWI est le pont que les logiciels de portefeuille peuvent utiliser pour découvrir un dispositif matériel, récupérer des clés publiques, afficher une adresse de réception et envoyer une transaction Bitcoin partiellement signée à des dispositifs tels que Ledger, Trezor, Coldcard, BitBox ou Jade pour approbation et signature. Le candidat successeur nommé dans l'avis, BHWI, vise à préserver la sortie de commande de style HWI avec une implémentation Rust.

Aucune transition n'est complète. HWI n'est pas archivé, aucune date de retraite n'a été fixée, et l'avis ne dit pas que les portefeuilles matériels pris en charge cesseront de fonctionner ou que les bitcoins des utilisateurs sont en danger. La pression immédiate pèse sur les équipes qui emballent HWI, invoquent sa ligne de commande ou s'appuient sur lui pour absorber les changements dans les dispositifs, les systèmes d'exploitation et les protocoles des fournisseurs.

Pourquoi la séparation de HWI est importante

HWI est à la fois une bibliothèque Python et un outil en ligne de commande. Il donne aux logiciels une interface pour les opérations courantes des portefeuilles matériels au lieu d'exiger une implémentation séparée pour chaque fournisseur.

Son objectif initial était d'apporter le support des portefeuilles matériels à Bitcoin Core. L'intégration a atteint les utilisateurs par le biais d'une frontière de signataire externe plutôt qu'en plaçant HWI à l'intérieur de Bitcoin Core. La documentation du signataire externe de Bitcoin Core décrit une commande configurable et utilise HWI comme exemple, tandis que le guide de HWI pour Bitcoin Core montre HWI utilisé pour la récupération de clés et la signature de transactions aux côtés d'un portefeuille Core.

Le mainteneur de HWI a déclaré que Python empêche des constructions déterministes, le processus de construction reproductible que Bitcoin Core utilise pour les binaires de publication, et empêche donc HWI d'être expédié avec Bitcoin Core. Cette séparation rend également HWI remplaçable en principe : un autre programme peut implémenter le contrat de signataire externe de Bitcoin Core. La couverture de CryptoSlate sur Bitcoin Core 22.0 a décrit l'arrivée du support des signataires externes en 2021.

Cependant, une surface de commande compatible n'est qu'une partie d'une migration. Les applications doivent toujours emballer un remplacement, tester les dispositifs et les opérations qu'elles exposent, et décider qui possède les corrections lorsque le comportement du firmware ou du système d'exploitation change.

BHWI aborde la contrainte d'emballage avec un noyau Rust plutôt qu'une application Python. Son design pourrait faciliter la distribution et l'utilisation reproductibles à partir de plusieurs environnements de programmation, mais chaque projet en aval doit encore vérifier que le remplacement couvre son propre ensemble de commandes, sa matrice de dispositifs et son processus de publication. Bitcoin Core peut tester une autre commande conforme derrière sa frontière de signataire externe ; d'autres logiciels qui consomment la ligne de commande de HWI doivent effectuer leur propre travail de compatibilité.

Cette distinction transforme l'annonce de maintenance en un problème de succession plutôt qu'un simple changement de statut du dépôt. L'interface de HWI peut être partagée, mais ses consommateurs ne l'utilisent pas tous ou ne la distribuent pas de la même manière.

La carte en aval montre trois types d'exposition : dépendances Python directes, wrappers autour de la ligne de commande de HWI, et projets qui maintiennent déjà une implémentation descendante séparée.

Specter Desktop, un coordinateur pour les portefeuilles Bitcoin Core, est la dépendance directe la plus claire. Sa description de projet explique son focus sur Bitcoin Core et les portefeuilles matériels, tandis que sa source fixe une version spécifique de HWI. BTCPay Server Vault prend une voie différente : son service local expose les dispositifs de signature connectés à travers un wrapper autour des requêtes en ligne de commande de HWI. Les deux nécessiteraient des tests d'intégration même si un remplacement acceptait des commandes familières.

Wasabi, un portefeuille axé sur la confidentialité, présente un exemple d'emballage. Un problème de projet de juillet a signalé que les builds Apple Silicon incluaient un exécutable HWI x86_64, soulevant un risque pour la détection des dispositifs soutenus par HWI, l'énumération, l'affichage d'adresse et la signature dans les builds affectés alors que la dépendance à Rosetta devenait moins tenable. Le problème concernait l'exécutable emballé, pas un échec des dispositifs de signature.

Sparrow, un portefeuille de bureau, montre pourquoi la transition peut se fragmenter au lieu de converger vers un seul successeur. Lark a commencé comme un port Java de Python HWI et fournit maintenant le chemin du portefeuille matériel de Sparrow. Sparrow n'est donc pas un cas de migration directe Python-HWI, mais il reste responsable d'une implémentation séparée issue de la même interface.

Les nouveaux modèles matériels sont là où le gel de HWI peut devenir visible. Sa matrice de support couvre les modèles Ledger, Trezor, BitBox, KeepKey, Coldcard et Blockstream Jade. Les capacités diffèrent selon le dispositif et le firmware, y compris les types de transactions, l'affichage d'adresse et les opérations de gestion des dispositifs. Un remplacement doit correspondre aux paires d'opérations de dispositifs requises, pas simplement reproduire les noms de commande.

L'écart entre le code en amont et la disponibilité en aval apparaît déjà dans les dossiers de support. HWI a publié la version 3.2.0 en février avec le support de BitBox02 Nova. Un rapport d'utilisateur de Specter en avril impliquait une configuration utilisant HWI 2.4.0 qui ne pouvait pas détecter le Nova. Le problème de Specter n'a pas identifié si la version épinglée, l'emballage, le firmware ou l'environnement local étaient à l'origine de l'échec, mais la chronologie montre que le support en amont et la disponibilité en aval peuvent diverger.

Selon la nouvelle politique de HWI, un fournisseur ou une équipe de portefeuille confronté au prochain modèle non pris en charge peut maintenir un fork, construire une intégration séparée, adopter une autre interface ou laisser cette combinaison non prise en charge. Ce qui disparaît, c'est le chemin normal pour intégrer le changement dans le projet partagé en amont.

BHWI a un responsable des tests, pas un transfert de production

BHWI s'attaque à la limitation architecturale de HWI avec un cœur Rust, sans I/O, qui laisse les choix de transport et d'exécution à l'appelant. Son espace de travail comprend des couches asynchrones, en ligne de commande et WebAssembly, et son package en ligne de commande construit un binaire hwi destiné à préserver la sortie compatible avec Python-HWI. Le dépôt étiquette toujours le projet comme étant en cours de développement.

L'instantané actuel du projet répertorie les modèles BitBox02, Coldcard, Jade et Ledger. Ses preuves de compatibilité publiées les plus solides sont plus étroites. La documentation de parité de BHWI décrit des tests différentiels et des portes finales qui exécutent la suite d'appareils HWI 3.2.0 non modifiée contre BHWI pour BitBox02, Coldcard, Ledger et Jade.

Ces tests réduisent le risque qu'une commande de remplacement renvoie des résultats différents pour les appareils couverts. Ils ne démontrent pas le comportement de production à travers la matrice plus large de HWI, chaque plateforme hôte, chaque format d'emballage ou les flux de portefeuille en aval complets. Le README et le document de parité de BHWI ne nomment également pas un portefeuille déjà expédié comme un remplacement de production pour HWI.

L'écart restant est organisationnel ainsi que technique. Le mainteneur de HWI a rendu l'archivage conditionnel à un remplacement approprié, tandis que BHWI a défini une architecture et une surface de test en croissance. Les équipes de portefeuille doivent encore décider si ses chemins d'appareils couverts sont suffisants, comment le distribuer et qui maintiendra l'intégration qu'elles expédient.

La dernière version probable de HWI établirait une limite amont fixe. Un nouvel appareil, un comportement de firmware ou une plateforme hôte pourraient alors nécessiter un patch en aval sans un chemin normal de retour dans HWI. Les projets qui regroupent Python HWI ont besoin de plans d'emballage et de publication. Les consommateurs en ligne de commande ont besoin de tests de compatibilité pour leurs propres appels. Des projets tels que Sparrow et Lark font face à une décision distincte concernant la poursuite de leur pile indépendante.

Le dépôt de HWI peut rester ouvert jusqu'à ce qu'un successeur soit approprié, mais son gel de contribution est déjà en vigueur. Le risque de succession commence lorsque le prochain changement de compatibilité arrive et que le pont partagé ne l'accepte plus.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.