Block Header

Imaginez le bloc comme un colis de transactions et l’en-tête comme sa fiche d’accompagnement. Il ne donne ni la liste des destinataires ni celle des montants. Il contient plutôt des empreintes cryptographiques : de courtes valeurs calculées à partir de données, permettant d’en détecter les modifications. L’une renvoie au bloc précédent. Une autre, appelée Merkle root, résume les identifiants des transactions de ce bloc. L’en-tête relie ainsi un contenu précis à une place précise dans l’historique. Ce n’est toutefois pas une copie miniature des transactions : leur contenu ne peut pas être reconstitué à partir de l’empreinte. [1] [4]

Le mineur prépare un bloc candidat et recherche un hash convenable, c’est-à-dire une empreinte interprétée comme un nombre. Ce nombre doit être inférieur ou égal à une cible imposée. Cette recherche est le Proof of Work : le mineur modifie des données et recommence le calcul, car il ne peut pas simplement prévoir un résultat acceptable. La variable la plus connue est le nonce, un nombre auxiliaire dans l’en-tête. Pour obtenir davantage de possibilités, il peut par exemple modifier des données de la Coinbase Transaction, la transaction particulière qu’il crée au début du bloc. Le Merkle root change alors lui aussi, donnant un nouvel en-tête. Les autres nœuds peuvent ensuite refaire rapidement le calcul pour vérifier le résultat. [1] [3] [4]

Une chaîne d’en-têtes permet de suivre les liens entre blocs et de vérifier le travail qui leur correspond sans télécharger toutes les transactions. Mais imaginez un bloc doté d’un Proof of Work valide dans lequel quelqu’un essaie de dépenser les fonds d’autrui sans la signature requise. Vérifier uniquement l’en-tête ne révèle pas ce problème. Un Full Node vérifie donc aussi les transactions, leurs signatures, les sorties non dépensées disponibles et la récompense autorisée. Un en-tête valide ne garantit pas la validité du bloc entier. [2]

Le champ nBits indique la cible à respecter par le hash. Il s’agit d’un codage compact de cette cible, pas du chiffre « difficulty » affiché par un explorateur de blocs. Le nœud vérifie également que la cible respecte les règles applicables à cet endroit de la chaîne. Le mineur ne peut pas non plus choisir une heure quelconque. Elle doit être postérieure à la médiane des 11 blocs précédents, c’est-à-dire la valeur du milieu une fois leurs heures classées, et ne pas dépasser la limite admise dans le futur. Ce n’est pourtant ni l’heure exacte de chaque paiement ni un chronomètre de la durée du minage. [2] [3]

L’ordre et la taille des champs sont fixes : version occupe 4 octets, le hash de l’en-tête précédent 32, le Merkle root 32, time 4, nBits 4 et nonce 4. Cela fait 80 octets, quel que soit le nombre de transactions. L’identifiant du bloc résulte de deux applications de SHA-256 à cet en-tête encodé exactement. Les champs numériques utilisent l’ordre little-endian, avec l’octet de poids faible en premier ; les hash suivent un ordre interne différent de l’affichage habituel d’un identifiant. Pour refaire le calcul, il ne suffit donc pas de coller les valeurs telles qu’un explorateur les présente. [1] [4]