VNISH GLOBAL · Académie
Fonctionnement d’une chaîne de minage ASIC : hash, share, pool et firmware
Un ASIC reçoit du travail du pool et évalue SHA-256 en boucle. Un résultat sous la cible du pool est une share ; seul un résultat sous la cible réseau peut devenir un bloc. Le firmware pilote la machine locale, pas le consensus Bitcoin ni le paiement du pool.
Méthode de travail
- Séparer consensus, pool, mineur et firmware.
- Ne pas confondre hashrate local, hashrate du pool et shares acceptées.
- Pour J/TH, utiliser puissance murale et hashrate du même état et de la même période.
- Noter source, unité, date, profil et conditions.
Examinons une situation
Scénario pédagogique, et non résultat rapporté par un client.
Prenons le cas hypothétique d’un opérateur qui observe un taux de hachage stable dans l’interface du mineur, mais un chiffre différent dans le compte du pool. Aucun de ces écrans ne permet, à lui seul, d’établir quel composant est responsable de l’écart. Commencez par noter ce que décrit chaque chiffre : l’appareil identifié, la source, l’unité et la période d’observation. Une fenêtre locale courte et une fenêtre plus longue côté pool ne permettent pas une comparaison à périmètre égal.
Distinguez ensuite une share acceptée d’un paiement. La share consigne un travail qui satisfait aux exigences du pool ; les règles de paiement du compte déterminent comment le travail crédité se transforme en solde. Considérez maintenant une seconde observation : l’interface reste accessible, mais le worker prévu n’a aucun nouveau travail accepté pendant la période examinée. Cela justifie de conserver l’état du pool et les journaux pertinents, pas de déclarer l’installation réussie sur la seule base de l’écran de connexion.
Conservez la version du firmware et le profil avec le relevé. Cette petite comparaison peut préciser la prochaine question sans deviner une panne, modifier un réglage ni promettre des revenus supplémentaires.
Limites et conditions d’arrêt
- Le firmware n’annule pas les limites du PSU, du câblage, du refroidissement ou du silicium.
- Une share n’est pas automatiquement un bloc ou un paiement.
- Air, Hydro et Immersion exigent des routes exactes distinctes.
Support réutilisable
| # | Champ | Vérifié | Preuve / note |
|---|---|---|---|
| 1 | travail (job) / fenêtre d’observation | □ | |
| 2 | hashrate local | □ | |
| 3 | hashrate du pool / shares | □ | |
| 4 | puissance à la prise / compteur / heure | □ | |
| 5 | modèle / carte / build / profil | □ |
Copiez cette structure dans le journal du changement ; n’y placez jamais de mots de passe, clés ou accès privés.
Termes utilisés dans ce guide
- Share
- Travail soumis à un pool pour validation par rapport à sa cible ; la plupart des shares ne sont pas des blocs valides du réseau.
- Fenêtre d’observation
- Période indiquée à laquelle se rapporte une mesure ou un relevé.
- Taux de hachage côté pool
- Estimation du travail de minage par le pool sur sa période d’observation indiquée, et non lecture directe de l’activité locale des puces.
Vérifiez votre compréhension
Ces questions vérifient la compréhension. Elles n’autorisent pas une installation et ne certifient pas un résultat.
Peut-on comparer deux taux de hachage sans vérifier leurs périodes ?
Afficher la réponse
Non. Consignez les deux sources, unités et périodes avant d’interpréter un écart.
Une share acceptée prouve-t-elle qu’un paiement a été reçu ?
Afficher la réponse
Non. L’acceptation des shares et la comptabilisation des paiements du pool sont des observations distinctes.
Que prouve une interface accessible ?
Afficher la réponse
Seulement que l’interface répond ; elle ne prouve ni un travail de minage accepté ni un fonctionnement stable.
Sources primaires
- Bitcoin Developer Guide - Mining Révisé 2026-09-10
- Stratum V2 - Mining Protocol Révisé 2026-09-10