Firmware à 0 % de frais de dev : ce que « sans frais de dev » signifie vraiment

« 0 % dev fee » est la phrase la plus citée dans le marketing des firmwares de minage — et l’une des moins examinées. Presque tous les firmwares aftermarket revendiquent quelque part sur leur page tarifaire une voie sans frais. Lisez l’astérisque et le portrait change : le zéro ne s’applique en général que si vous dirigez votre hashrate vers leur pool. Voici un regard honnête sur le fonctionnement réel des dev fees, sur ce que les chiffres signifient vraiment (en fourchettes, pas les chiffres uniques soigneusement répétés partout), et sur la façon de distinguer un véritable modèle de don d’un prélèvement discret — en lisant le code source plutôt qu’en se fiant au badge.

Ce qu’est vraiment un dev fee (et comment le prélèvement discret s’opère)

Lorsque vous flashez un firmware personnalisé sur un Antminer, vous confiez le code d’autrui pour communiquer avec vos hashboards, gérer votre connexion au pool et soumettre vos shares. Un dev fee est la façon dont la plupart des auteurs de firmwares aftermarket se font rémunérer pour ce travail : pendant un petit pourcentage du temps, votre mineur mine pour eux plutôt que pour vous.

Mécaniquement, c’est en général l’une de deux méthodes. La plus courante est la redirection de pool : pendant environ 2–3 % du temps, le firmware remplace silencieusement votre pool configuré par l’adresse du pool du développeur, mine quelques shares là-bas, puis revient. Vous ne le voyez jamais dans le tableau de bord de votre propre pool, car ces shares n’ont jamais été soumis sous votre compte. La seconde méthode est le minage de fee en tâche de fond — une file de travail à faible priorité qui prélève un pourcentage avant même que vos shares ne quittent l’appareil. Dans les deux cas, le calcul est le même : un dev fee de 2.5% sur un mineur qui gagne l’équivalent de $5/day en Bitcoin représente environ $0.12/day, soit à peu près $45/year, par machine. Exploitez un rack et la somme s’accumule.

Rien de tout cela n’est intrinsèquement louche. Le firmware est un travail difficile, ingrat, 24 h sur 24, et le dev fee est le moteur qui le finance. Soyons clairs d’emblée : les firmwares qui facturent un fee ont mérité ce droit. Braiins, VNish et Luxor ont chacun passé des années à bâtir des outils dont des millions de mineurs dépendent aujourd’hui. Le problème n’est pas qu’un fee existe — c’est qu’il est souvent obfusqué, et que le « 0 % » marketing est fréquemment conditionné au pool d’une façon que personne ne lit. Mettons les vrais chiffres sur la table.

Le tableau honnête des dev fees (en fourchettes, pas en chiffres fixes)

Vous verrez des chiffres uniques répétés partout sur Internet — « BraiinsOS est à 2 % », « VNish est à 3 % ». Ce sont des simplifications. Les vrais fees sont des fourchettes qui varient selon le modèle de mineur, la version du firmware et le pool que vous utilisez. Voici la version ancrée dans les faits, recoupée avec notre matrice de fonctionnalités des firmwares :

Deux points méritent d’être dits clairement. Premièrement, le stock firmware Bitmain est aussi à « 0 % » — mais il est fermé, chargé de télémétrie, et vous empêche d’ajuster votre propre matériel, ce qui est précisément la raison d’être d’une industrie aftermarket. Un fee à 0 % sur un firmware que vous ne contrôlez pas n’est guère une aubaine. Deuxièmement, ces fees de 2–2.8% sont le prix d’une ingénierie véritablement excellente. Nous détaillons la comparaison fonctionnalité par fonctionnalité dans notre comparaison de firmwares — c’est la matrice à lire si vous voulez peser les fees face aux fonctionnalités (qualité de l’autotuning, support Stratum, couverture des modèles) plutôt que de courir après le chiffre le plus bas isolément.

Les astérisques du « 0 % » que personne ne lit

C’est ici que le marketing et la réalité divergent. Plusieurs firmwares annoncent un « 0 % dev fee » — et c’est techniquement vrai. Le petit caractère, c’est que le zéro est conditionnel au pool :

• BraiinsOS+ → 0 % sur Braiins Pool. Exécutez BraiinsOS+ et pointez-le vers le pool de Braiins et vous ne payez réellement aucun fee de firmware distinct. Pointez-le vers n’importe quel autre pool et le fee autonome de 2–2.5% s’applique. C’est un modèle d’affaires raisonnable — ils monétisent via le pool plutôt que via le firmware — mais « 0 % dev fee » sans la condition de pool, c’est la moitié de la phrase.
• LuxOS → exempté sur Luxor Pool. Même logique : Luxor exonère le fee d’environ 2.8% lorsque vous minez sur le pool Luxor. Hors pool, vous payez.
• VNish → pas de niveau gratuit. VNish ne brandit pas de zéro lié à un pool; le fee s’applique dans tous les cas. Il y a une forme d’honnêteté là-dedans — au moins, il n’y a pas d’astérisque.

Nous ne moquons pas ces modèles. Un firmware financé par le pool peut être un échange parfaitement équitable, et dans certains cas le pool est excellent. Mais cela change le calcul : un « 0 % » qui exige de renoncer au choix de pool n’est pas gratuit — vous avez simplement payé dans une autre monnaie (la destination de votre hashrate, et la centralisation qui s’ensuit lorsque tout le monde se rabat sur un seul pool). Pour un mineur soucieux de souveraineté, la destination de vos shares n’est pas un détail mineur. Choisir son propre pool est l’un des rares leviers qu’un mineur individuel possède sur la décentralisation de Bitcoin, ce qui est précisément la raison pour laquelle nous nous en préoccupons.

Pourquoi les outils de piratage « NoDevFee » sont une mauvaise idée

Cherchez « remove dev fee » et vous trouverez une véritable industrie artisanale d’« NoDevFee » outils — chargeurs, binaires patchés et astuces de redirection DNS qui promettent d’éliminer le fee des firmwares fermés. Passez votre chemin. Voici la réalité d’ingénierie honnête :

• Vous exécutez un binaire inconnu en root sur une machine qui imprime de l’argent. Pour « retirer » un fee d’un firmware fermé, ces outils patchent ou remplacent le composant même qui contrôle vos hashboards et vos identifiants de pool. Vous n’avez aucun moyen d’auditer ce qu’ils ont changé d’autre. Le résultat le plus souvent rapporté sur le terrain est que le fee est redirigé vers l’auteur de l’outil plutôt que supprimé — vous n’avez pas tué le prélèvement, vous avez seulement changé qui vous siphonne.
• Cela peut bricker votre mineur. Patcher un firmware que vous ne pouvez pas lire est exactement le type d’opération qui se termine par une carte de contrôle morte et une session de récupération sur SD-card — si vous avez la chance que la récupération soit même possible.
• C’est une impasse de confiance. Toute la raison de s’inquiéter d’un fee de 2.5%, c’est que vous ne voulez pas qu’un inconnu prélève une part de votre hashrate. Résoudre cela en exécutant le correctif non audité d’un autre inconnu n’est pas une solution. C’est le même problème sous un autre chapeau.

La réponse propre à « je ne veux pas payer de dev fee » n’a jamais été un outil de piratage. C’est un firmware honnête par conception — où la logique du fee est ouverte, le défaut est zéro, et vous pouvez le vérifier vous-même plutôt que de faire confiance à la parole de quiconque, y compris la nôtre.

Don, pas détournement : le modèle DCENT_OS

DCENT_OS — le micrologiciel open source de D-Central pour certains Antminer — est conçu sans frais de développement obligatoires. Cette affirmation doit être vérifiée contre la source, la provenance du binaire et la configuration de la build testée; elle ne constitue ni un audit indépendant ni une promesse de préparation à la production.

Ce qu’il y a, c’est un champ de don optionnel et transparent dans le tableau de bord — un pourcentage configurable que vous pouvez régler vous-même si vous souhaitez soutenir le projet. Il vaut 0 % par défaut. Si vous n’y touchez jamais, vous ne payez rien, et 100 % de votre hashrate vous appartient. Si vous jugez que le firmware a mérité quelques sats, vous pouvez fixer une contribution et suivre exactement où elle va. Voilà la distinction qui compte : c’est un don, pas un détournement. Rien n’est prélevé par défaut et rien n’est caché — le mécanisme de dev fee est ouvert et auditable dans le code source, là où la plupart des firmwares l’obfusquent.

Les firmwares qui facturent 2–2,8 % financent une véritable ingénierie, et D-Central s’appuie sur le chemin tracé par Braiins, VNish et Luxor. Le modèle sans frais obligatoires est un autre compromis, pas une supériorité morale. Des artéfacts signés existent pour les voies exactes S9 XIL et S19j Pro XIL, mais leurs preuves d’installation restent incomplètes. Ils sont expérimentaux, sous garde et non prêts pour la production. Consultez la page DCENT_OS et le registre de preuves avant tout téléchargement.

Comment vérifier un dev fee en open source

Voici la compétence pratique qui rend tout ce qui précède secondaire : lorsque le firmware est open-source, vous n’avez pas à croire l’affirmation sur le fee — vous pouvez la vérifier. C’est le vrai argument en faveur du firmware ouvert, et il dépasse tout pourcentage isolé. Un prélèvement que l’on peut lire est un prélèvement qui ne peut se cacher.

Si vous savez lire le code source (ou suivre quelqu’un qui le sait), voici à peu près à quoi ressemble l’audit d’un fee :

1. Trouvez le code de connexion au pool. Tout dev fee qui fonctionne par redirection doit, à un moment donné, remplacer l’URL de pool que vous avez configurée par une autre. Parcourez le code source pour la logique de connexion pool/stratum et cherchez toute adresse qui n’est pas celle que vous avez définie. Dans un firmware honnête, il n’y a qu’un seul endroit où votre pool est configuré.
2. Cherchez la logique de découpage temporel ou de file de travail. Le minage de fee fonctionne en allouant un pourcentage des cycles de travail ailleurs. Recherchez des constantes de pourcentage, des minuteries, ou une source de travail secondaire alimentant le soumetteur de shares. Un « 0.025 » codé en dur près de la boucle de minage raconte sa propre histoire.
3. Vérifiez la valeur par défaut du champ de don et son câblage. Dans un firmware avec une contribution configurable (comme DCENT_OS), confirmez que la valeur par défaut est bien zéro et suivez où une valeur non nulle envoie les shares. La valeur que vous fixez doit être la seule en jeu.
4. Privilégiez les builds reproductibles. L’étalon-or, c’est de pouvoir compiler le firmware vous-même à partir du code source et d’obtenir un binaire qui correspond à ce qui est distribué — ainsi vous savez que le code en exécution est celui que vous avez lu. Les builds Buildroot reproductibles sont l’intention de conception de DCENT_OS; traitez « vous pouvez le vérifier vous-même » comme la barre à exiger de tout firmware ouvert.

Avec un firmware fermé (stock, VNish, LuxOS, ou les composants fermés de BraiinsOS+), vous ne pouvez tout simplement pas le faire — vous faites confiance au badge et à la marque. Ce n’est pas toujours une erreur; la confiance est une chose raisonnable à accorder à un développeur au long parcours. Mais « davantage d’options pleinement auditables », c’est, à notre avis, la même chose que « davantage de décentralisation ». Plus il y a de mineurs qui peuvent vérifier leur propre pile logicielle, plus il devient difficile pour quiconque — y compris nous — de les siphonner en silence. C’est le principe qui mérite d’être optimisé, et il se situe un cran au-dessus de tout chiffre de dev fee : il s’agit de posséder la boîte que vous faites tourner, le même instinct de sauvegarde de votre souveraineté qui sous-tend tout, de l’exécution de votre propre nœud au maintien de votre propre infrastructure résiliente.

Alors, quel firmware devriez-vous réellement utiliser?

Honnêtement? Pour une flotte de production aujourd’hui, les options matures et éprouvées au combat sont celles qui facturent un fee — et ce fee vous achète des années d’affinage de l’autotuning et un large support de modèles. Ne choisissez pas un firmware sur le seul dev fee; choisissez-le sur le portrait d’ensemble. Si vous voulez peser les fees face aux fonctionnalités côte à côte, la matrice complète de comparaison des firmwares détaille chaque colonne — dev fee, statut open-source, support Stratum et modèles supportés — pour que vous puissiez décider avec les astérisques bien visibles.

DCENT_OS vise une pile de micrologiciel contrôlable par l’opérateur et sans frais obligatoires. Le daemon, le tableau de bord et l’intégration Buildroot sont publics sous GPL-3.0; une image Antminer complète exige aussi des entrées de démarrage fabricant documentées mais non redistribuées. Les artéfacts actuels restent sous garde. Vérifiez le modèle, la carte et les preuves avant de conclure qu’une build est installable.

Foire aux questions