47 / 691ASIC

ASIC Miner

Matériel de minage spécialisé

Un ASIC de minage Bitcoin est un circuit intégré spécialisé conçu pour tester des candidats SHA-256 au Proof of Work avec une vitesse et une efficacité énergétique extrêmes ; le micrologiciel, le contrôleur et le pool ou le propre nœud de l’opérateur lui fournissent du travail distinct.

ASIC désigne la spécialisation du matériel, pas un pouvoir sur le consensus. La puce calcule de façon répétée le double-SHA-256 d’en-têtes de blocs candidats de 80 octets et signale les résultats qui satisfont le target attribué. Un ASIC Miner complet nécessite aussi un contrôleur, une alimentation, un système d’horloge, du refroidissement, un micrologiciel et une source de modèles de blocs ou de tâches de pool. Le hashrate mesure le nombre de tentatives par seconde ; J/TH mesure l’énergie par terahash. Aucun des deux ne garantit à lui seul un bénéfice ni le droit de modifier les règles de Bitcoin.

Un ASIC réalise une tâche précise directement dans le silicium au lieu d’employer une logique d’instructions généraliste. Le minage est ainsi passé historiquement des CPU et GPU aux FPGA, puis aux ASIC SHA-256 : un chemin de données fixe permet de calculer bien plus de hash par joule. La contrepartie est le manque de flexibilité : un ASIC de minage SHA-256 n’est pas un ordinateur généraliste qu’il suffit de reprogrammer lorsque la tâche change. [Bitcoin Developer Guide — Mining] [Bitaxe — open-source ASIC miner hardware]

Le Proof of Work de Bitcoin calcule SHA-256(SHA-256(en-tête)) à partir de l’en-tête sérialisé de 80 octets. Celui-ci contient version, le hash du bloc précédent, Merkle Root, timestamp, nBits et un Nonce de 32 bits. La puce peut réutiliser en interne des résultats intermédiaires pour les parties inchangées de l’en-tête, mais le réseau évalue uniquement le hash obtenu par rapport au target (hash ≤ target), et non l’optimisation particulière du mineur. [Bitcoin Developer Guide — Mining] [Bitcoin Core v29.0 — CheckProofOfWorkImpl]

Le Nonce de 32 bits n’offre à lui seul que 2^32 valeurs, très vite épuisées aux hashrates modernes. Le mineur modifie donc d’autres variables : l’Extranonce dans la coinbase modifie la transaction coinbase et donc le Merkle Root ; nTime peut être ajusté dans les limites du consensus, et la proposition BIP320 réserve des version bits à un usage général. Stratum V2 attribue en outre aux appareils des portions distinctes de l’espace de recherche afin qu’ils ne calculent pas les mêmes candidats. [BIP 320 — nVersion bits for general purpose use] [Stratum V2 — Mining Protocol specification]

L’ASIC ne sélectionne pas lui-même les transactions et n’invente pas les règles. Un Full Node ou un fournisseur de modèles de blocs assemble un bloc candidat ; BIP22 standardise getblocktemplate et BIP23 ses extensions pour le minage en pool. Le pool ou le proxy en tire une tâche avec un target et des variables pour l’appareil. Stratum V2 sépare Mining Protocol, Job Declaration et Template Distribution, de sorte que la distribution du travail et le choix des transactions peuvent constituer des rôles distincts. [BIP 22 — getblocktemplate fundamentals] [BIP 23 — getblocktemplate pooled mining] [Stratum V2 — Protocol overview] [Bitcoin Core — getblocktemplate RPC]

Le pool fixe généralement un share target beaucoup plus facile à satisfaire que le target du réseau Bitcoin. Un share satisfaisant le target du pool apporte une preuve statistique du travail effectué pour la comptabilisation des récompenses ; seul un hash exceptionnellement rare satisfaisant le target du réseau est candidat à un bloc valide. La difficulté du pool modifie donc la fréquence des shares, pas la difficulté du consensus ni le hashrate physique de la machine. [Bitcoin Developer Guide — Mining]

Le hashrate indique le nombre de hash par seconde. La puissance absorbée se mesure en watts, et l’efficacité s’exprime couramment par J/TH = W divisé par TH/s. Une valeur J/TH plus faible signifie moins d’énergie électrique pour le même volume de recherche. Le bénéfice dépend toutefois aussi de la difficulté du réseau, du prix du BTC, des frais, du temps de fonctionnement, de l’électricité, du refroidissement, du financement et de l’amortissement du matériel. [Braiins OS — Autotuning] [Bitaxe — open-source ASIC miner hardware]

Même des puces de même type ne sont pas électriquement identiques : les variations de fabrication modifient les courants de fuite, les délais de fonctionnement et la marge de tension nécessaire. Le micrologiciel peut donc régler la fréquence et la tension du cœur. Le sous-cadencement améliore souvent J/TH, tandis que le surcadencement accroît le hashrate au prix d’une hausse disproportionnée de la consommation et de la chaleur. L’autotuning recherche un point de fonctionnement adapté à la puce ou au hashboard concerné. [Braiins OS — Autotuning]

Un mineur ne se résume pas à l’ASIC. Ses résultats sont limités par l’alimentation, la régulation DC-DC, les connecteurs, les hashboards, les ventilateurs ou le circuit de refroidissement liquide, ainsi que le contrôleur. Une température élevée, la poussière, un ventilateur défectueux, une tension instable ou un cadencement agressif augmentent les erreurs matérielles et le risque d’arrêt. L’efficacité de la puce seule n’est donc pas celle de l’ensemble mesurée à la prise électrique. [Braiins OS — Autotuning] [Bitaxe — open-source ASIC miner hardware]

Les ASIC élèvent les barrières financières et techniques du minage compétitif et créent des économies d’échelle pour les achats, l’énergie, les réparations et les infrastructures. Cela peut concentrer les fabricants ou le hashrate, mais ne signifie pas automatiquement un contrôle du consensus. Il faut distinguer la concentration de la fabrication des puces, celle des pools, celle des sites physiques et celle des véritables propriétaires du hashrate. [Bitcoin Developer Guide — Mining]

Un ASIC peut rechercher des en-têtes et travailler sur une tâche précise selon le logiciel en amont. Il ne peut pas rendre valide un bloc invalide, modifier la limite de l’offre, dépenser les pièces d’autres propriétaires ni forcer un Full Node à accepter d’autres règles. L’opérateur doit vérifier le micrologiciel, le point de connexion au pool, le hashrate observé par le pool, les shares rejetés, la puissance absorbée à la prise, les températures et sa propre politique de création des modèles de blocs. [Bitcoin Developer Guide — Mining] [Bitcoin Core — getblocktemplate RPC] [Bitcoin Core v29.0 — CheckProofOfWorkImpl]

Pour une vision complète, lisez aussi Minage, Hashrate, SHA-256, En-tête de bloc, Nonce, Extranonce. Cette entrée est également citée par Mining Pool, Hashrate, Nonce, Braiins.

DOC · 001BIP 22 — getblocktemplate fundamentalsSpécification ↗DOC · 002BIP 23 — getblocktemplate pooled miningSpécification ↗DOC · 003BIP 320 — nVersion bits for general purpose useSpécification ↗DOC · 004Stratum V2 — Mining Protocol specificationSpécification ↗DOC · 005Stratum V2 — Protocol overviewSpécification ↗DOC · 006Bitcoin Developer Guide — MiningDocumentation ↗DOC · 007Braiins OS — AutotuningDocumentation ↗DOC · 008Bitaxe — open-source ASIC miner hardwareSource primaire ↗DOC · 009Bitcoin Core — getblocktemplate RPCDocumentation ↗DOC · 010Bitcoin Core v29.0 — CheckProofOfWorkImplSource primaire ↗
Sources d’abord · Pas un conseil financier