ASICBoost

Pour traiter des commandes similaires, on peut préparer leurs informations communes une seule fois, puis terminer chaque commande séparément. Cette image aide à comprendre ASICBoost. Timo Hanke l’a décrit en 2016 en mentionnant sa collaboration avec Sergio Demian Lerner. Un ASIC est une puce conçue pour un calcul particulier ; réorganiser ce travail évite des répétitions. Ni SHA-256, la fonction de hachage utilisée, ni les règles de Bitcoin ne changent. Le double hash final de l’en-tête doit rester inférieur ou égal à la cible, et le bloc entier doit être valide. [1]

L’octet est une unité qui mesure la taille des données numériques. L’en-tête résume les données du bloc sur 80 octets. Le premier passage de hachage traite 64 octets, puis les 16 restants avec le remplissage prévu. La Merkle root, l’empreinte commune des transactions, traverse cette frontière : ses 4 derniers octets sont dans la seconde partie. Celle-ci contient aussi l’heure, bits, le codage compact de la cible de minage, et nonce, le compteur modifié entre les essais. Les champs que l’on change déterminent donc quels calculs peuvent être réutilisés. [1]

Hanke appelle colliding work items les tâches convenablement regroupées. Leurs premières parties d’en-tête diffèrent et produisent des midstate distincts, les états intermédiaires du calcul. En revanche, la partie appelée Message reste identique. Pour un nonce donné, la puce peut partager le message schedule, les valeurs auxiliaires servant au traitement de la seconde partie du premier SHA-256. Chaque calcul poursuit ensuite son chemin depuis son propre état intermédiaire. Ce ne sont pas des hashes finaux identiques, ni une fonction cassée. La collision désigne ici une correspondance partielle des entrées ; les premières parties des en-têtes diffèrent. [1]

Sergio Demian Lerner distingue overt et covert ASICBoost. Overt modifie des bits autorisés de nVersion, le champ de version de l’en-tête, sans rechercher une correspondance partielle de la Merkle root. Covert recherche cette correspondance : les 4 derniers octets de la Merkle root restent identiques tandis que sa première partie change. On peut modifier des données de transaction autorisées ou l’ordre des transactions, tout en préservant leurs dépendances et la correspondance entre les empreintes enregistrées et les données du bloc. Des versions d’en-tête différentes ne prouvent à elles seules ni une économie d’énergie ni l’identité de l’opérateur. [2]

Un pool coordonne le travail des mineurs. Son serveur, le service informatique avec lequel l’appareil communique, accepte les résultats selon les conditions convenues. L’appareil de Pierre ne peut pas modifier librement l’en-tête. Le document portant le numéro BIP310 décrit une négociation par mining.configure : version-rolling.mask indique les bits modifiables, et la réponse retient l’intersection des possibilités du mineur et du serveur. Ce masque décrit des positions autorisées, pas une promesse de vitesse. La condition version_bits & ~last_mask == 0 impose que les bits soumis restent dans le dernier masque valide. Une notification mining.set_version_mask s’applique immédiatement, sans attendre la tâche suivante. Le firmware, le logiciel qui commande l’appareil, doit respecter cet accord. [3]

BIP320 propose 16 bits nVersion à usage général ; BIP323, proposé pour le remplacer, en décrit 24. Au moment de cette révision, les deux documents ont le statut Draft, donc de proposition. Ce statut ne signifie à lui seul ni qu’aucune implémentation n’existe ni que tous les pools la prennent en charge. Le document décrit l’usage prévu du champ ; une connexion dépend du masque et du logiciel réellement utilisés. Pierre ne déduit donc pas les permissions de son appareil d’un numéro de BIP et ne confond pas proposition et changement automatique des règles du réseau. [4] [5]

Hanke exprime l’économie du modèle par x × (n − 1) / n. Ici, x représente la part du calcul partageable, et n le nombre de tâches adaptées. Avec x = 25% et n = 4, on obtient 18.75%. La préparation commune est réalisée ensemble plutôt que répétée pour chaque tâche. Ce résultat concerne le modèle de calcul, pas automatiquement la même baisse de puissance consommée pour n’importe quel appareil. Les autres circuits et les conditions d’exploitation comptent également. Il ne faut donc pas reprendre ce pourcentage tel quel comme gain de performance ou de revenu. [1]

Pierre vérifie d’abord la prise en charge par la puce, le firmware et le pool. Il contrôle ensuite l’acceptation du travail par le pool et mesure l’appareil entier dans des conditions comparables. J/TH signifie joules par térahash : l’énergie nécessaire à mille milliards de tentatives de hachage. Pour comparer, les mesures doivent couvrir les mêmes composants de l’appareil et la même période. Le nom ASICBoost ne remplace pas cette mesure. Il ne signifie pas non plus overclocking, qui augmente la fréquence de fonctionnement, et ne garantit ni bloc trouvé ni bénéfice. Il permet d’effectuer certains calculs plus efficacement lorsque toute la configuration s’y prête. [1] [3]