Midstate : optimisation du hachage SHA-256

Le midstate est un état intermédiaire de SHA-256 que le matériel calcule une fois, puis réutilise tant que le début de l'en-tête ne bouge pas. Il n'apparaît dans aucun champ du protocole Bitcoin : c'est une optimisation interne, mais elle explique une partie des shares rejetées quand elle est mal gérée.

SHA-256 travaille par blocs de 64 octets

SHA-256 ne consomme pas 80 octets d'un seul coup. Il traite le message par blocs de 64 octets, en mettant à jour un état interne de huit mots. Un en-tête de bloc faisant 80 octets, le premier bloc de message correspond aux 64 premiers octets de l'en-tête, et le second contient les 16 octets restants plus le padding imposé par la fonction.

Ces 64 premiers octets contiennent la version, le hash du bloc précédent et le début de la racine de Merkle. Ils ne changent pas quand seul le nonce tourne, puisque nonce, nBits et nTime se trouvent dans la queue de l'en-tête, donc dans le second bloc de message.

Le midstate est précisément l'état interne après absorption du premier bloc de 64 octets. Il se calcule une fois pour un en-tête dont la tête est figée, après quoi chaque essai de nonce ne reprend que la seconde compression, puis le second SHA-256 du double hash.

Le digest final reste identique à celui d'un calcul complet. Il ne s'agit donc pas d'un raccourci cryptographique, mais d'une factorisation de travail répété.

Pourquoi les mineurs s'en servent

Sans midstate, chaque essai rejouerait le premier bloc de 64 octets, pourtant inchangé. Avec, le silicium concentre sa boucle serrée sur la partie qui varie. Sur un ASIC, c'est le régime normal : les cœurs reçoivent un midstate et une queue d'en-tête, pas 80 octets complets à chaque tick.

Trois conséquences en exploitation :

• Le travail répété disparaît tant que racine de Merkle, prevhash et version restent stables.
• Le midstate périme instantanément dès que la racine de Merkle change, qu'il s'agisse d'un nouvel extraNonce, d'un nouveau template ou d'une autre coinbase. Il faut le recalculer avant de relancer le nonce.
• Un midstate incohérent avec le job produit des hashes qui ne correspondent à aucun en-tête réel. Le pool refuse alors les shares, alors que le hashrate local reste flatteur. C'est un des cas où l'écart entre hashrate local et hashrate pool ne vient ni du réseau ni du matériel.

Le midstate n'apparaît jamais dans un bloc publié. Un nœud revérifie le double SHA-256 des 80 octets complets, donc un midstate erroné ne produit tout simplement aucun hash valide.

Ce qu'il ne change pas

Réutiliser un état intermédiaire ne modifie ni la cible, ni la difficulté, ni la probabilité qu'un hash tiré au hasard passe sous la cible. Cela change uniquement la quantité de travail redondant que le circuit évite. Le midstate n'est donc pas un levier de rendement, et un vendeur qui le présenterait comme tel décrirait le fonctionnement normal de n'importe quel ASIC.

Les modes de recherche qui font varier certains champs d'en-tête pour conserver un midstate plus longtemps relèvent d'un autre sujet, traité dans la fiche ASICBoost.

Ce que ça donne sur une machine saine

1. Le job arrive avec prevhash, branches de Merkle, nBits, nTime et coinbase.
2. Le firmware construit l'en-tête, calcule le midstate, et pousse le lot aux puces.
3. Les puces balaient le nonce, et parfois d'autres bits autorisés.
4. Un nouveau job, ou un extraNonce qui change la racine de Merkle, invalide le midstate, et le cycle repart à l'étape 2.

Si vous déboguez des shares rejetées, aucune option de midstate n'est à chercher dans une interface. Regardez d'abord le template reçu et l'horloge du contrôleur : un midstate n'est valide que pour un seul préfixe d'en-tête, et tout ce qui décale ce préfixe le rend inutilisable.