Firmware Bitmain stock vs custom : que choisir ?

Le firmware d'un ASIC Bitmain, Antminer et dérivés, est le logiciel du contrôleur : interface web, agents de minage, régulation des ventilateurs et des alimentations, dialogue avec les hashboards. L'image livrée par le constructeur s'appelle le stock OS. D'autres éditeurs publient des images dites custom, comme Braiins OS+, VNish ou LuxOS. Le choix entre les deux se joue autant sur le contrat et sur la salle que sur le logiciel.

Ce que fait le stock OS

L'image constructeur vise un comportement supporté : mise à jour officielle, profils de puissance documentés, télémétrie de base, et parfois un agent cloud du fabricant. Elle est conçue autour des pièces et du service après-vente tels que le constructeur les définit, ce qui est exactement ce qu'on attend d'elle quand une machine part en RMA.

Ses limites habituelles : moins d'options de profil par board, une API plus pauvre, et parfois un écosystème de compte constructeur pour accéder à certaines fonctions. Sur le plan sécurité, elle ne bénéficie d'aucune protection particulière : c'est un système Linux embarqué exposé sur le réseau local, avec les défauts de configuration classiques, mot de passe d'usine en tête. Changer ce mot de passe et isoler les machines sur un VLAN dédié compte davantage que le choix de l'image.

Ce qu'ajoute un firmware custom

Les firmwares tiers du marché apportent en général :

• des profils d'underclock et d'overclock réglables board par board ;
• des tableaux de bord et des API nettement plus riches ;
• parfois un client de pool ou un protocole différent selon les versions ;
• une télémétrie agrégée à l'échelle de la flotte ;
• des frais de licence, souvent prélevés sous forme de pourcentage du hashrate.

Ce dernier point mérite un calcul explicite : une licence prélevée sur le hashrate doit être comparée au gain d'efficacité annoncé, sur vos propres machines et à votre tarif électrique. Aucune de ces fonctions ne garantit un hashrate, une efficacité ou une durée de vie. Un profil plus agressif augmente la consommation et la température, un profil plus doux fait l'inverse, et les chiffres d'une fiche marketing ne se transposent pas d'une salle à l'autre.

Les six risques à arbitrer

• Garantie et SAV. Le constructeur peut refuser une prise en charge si l'image n'est plus la sienne. C'est une clause contractuelle, vérifiable avant de flasher plutôt qu'après une panne.
• Brique et irréversibilité partielle. Une écriture d'image interrompue, une image inadaptée au modèle ou à la révision de contrôleur, ou un outil non prévu pour cette carte, peut laisser la machine inamorçable. Les voies de récupération dépendent du couple modèle et image, et se vérifient dans la documentation de l'éditeur avant l'opération.
• Stabilité thermique et électrique. Un firmware qui pousse fréquence et tension au-delà du profil constructeur augmente le risque de reset, de hashboard muette et d'usure d'alimentation. Le risque inverse existe aussi, avec une régulation de ventilateur mal réglée ou un capteur mal lu.
• Surface d'attaque. Une image tierce est un logiciel que vous n'avez pas audité. Elle peut embarquer de la télémétrie, un canal de mise à jour silencieux, ou une adresse de paiement de secours. La question à poser à l'éditeur est simple : quelle politique de divulgation de vulnérabilités, et quel délai de correctif.
• Conformité d'hébergement. Un site peut interdire les images non approuvées, pour des raisons de sécurité de salle, d'homogénéité de parc ou de couverture assurantielle. Flasher sans accord écrit expose à une rupture de contrat.
• Compatibilité du monitoring. Un agent custom peut casser un collecteur SNMP, un overlay de supervision ou un nommage de worker. C'est un changement de pile logicielle, à tester sur une machine avant de le déployer sur un parc.

Cinq questions avant de décider

1. Qui édite l'image, sous quelle licence, avec quelle politique de mise à jour et de traitement des vulnérabilités ?
2. Le modèle et la révision de contrôleur et de hashboard sont-ils explicitement listés comme supportés par l'éditeur ?
3. Qui a le droit de changer l'image : vous, ou l'hébergeur ?
4. Quel profil thermique la salle autorise-t-elle réellement, mesuré à l'entrée des châssis en pointe d'été ?
5. Pouvez-vous observer hashrate, rejets et températures indépendamment du tableau de bord du firmware, via le pool et des sondes externes ? Sans cette mesure indépendante, vous n'aurez aucun moyen de constater qu'une image dégrade vos machines.

Le stock OS privilégie le chemin constructeur et la couverture SAV. Le custom privilégie le contrôle fin et la télémétrie, en transférant une partie du risque vers un éditeur tiers, votre garantie et votre salle. Si vous hésitez, gardez le stock sur les machines sous garantie et testez le custom sur une machine hors garantie, avec un témoin en profil d'origine à côté.