Glossaire / Minage et consensus
En-tête de bloc
Aussi appelé En-tête.
- Qu'est-ce qu'un en-tête de bloc ?
- Un en-tête de bloc est le résumé de 80 octets d'un bloc : version, hash de l'en-tête précédent, racine de Merkle, horodatage, nBits et nonce, et c'est la partie que les mineurs hachent réellement.
Les mineurs ne hachent jamais directement les paiements. Ils hachent cet enregistrement de taille fixe, qui engage la liste des transactions par la racine de Merkle et tous les blocs antérieurs par le hash de l'en-tête précédent. Quatre-vingts octets par bloc, c'est assez petit pour que la chaîne complète des en-têtes depuis janvier 2009 tienne aisément sur un téléphone, et c'est ce fait qui rend la vérification légère possible.
Comment cela fonctionne
Un en-tête de bloc comporte six champs dans un ordre fixe, et leurs décalages en octets ne bougent jamais.
La version occupe les octets 0 à 3. Le hash de l'en-tête du bloc précédent occupe les octets 4 à 35. La racine de Merkle occupe les octets 36 à 67. L'horodatage, en secondes depuis l'époque Unix, se situe aux octets 68 à 71. nBits, la cible de difficulté encodée, se situe aux octets 72 à 75. Le nonce remplit les octets 76 à 79. Chaque champ est stocké en petit-boutiste, ce qui explique que l'hexadécimal affiché dans un explorateur semble inversé en octets par rapport à l'hexadécimal d'un vidage brut de bloc.
Le hash du bloc ne fait pas partie de ces champs. Il est calculé en appliquant SHA-256 deux fois sur les 80 octets, et les nœuds le dérivent au lieu de s'y fier, ce qui explique précisément qu'un bloc ne puisse pas mentir sur sa propre identité. La preuve de travail est la même opération avec une comparaison en plus : le nombre obtenu doit être inférieur ou égal à la cible qu'encode nBits.
Deux des champs portent des règles qui surprennent. L'horodatage n'a pas besoin d'être exact. Il doit seulement dépasser l'horodatage médian des onze blocs précédents et rester à moins de deux heures de l'horloge du nœud récepteur, de sorte que des en-têtes aux heures légèrement désordonnées sont ordinaires et valides. Le champ version n'est plus non plus un simple compteur. La signalisation de soft fork sous BIP9 et le version rolling sous BIP320 empruntent tous deux des bits à ce champ, de sorte qu'un numéro de version dans un en-tête moderne est un champ de bits plutôt qu'un numéro de version logicielle.
Où le voit-on
Les en-têtes de bloc sont la première chose qu'un nouveau nœud télécharge et la seule chose que de nombreux portefeuilles conservent.
Bitcoin Core synchronise les en-têtes en premier depuis la version 0.10, publiée en février 2015. Le nœud récupère et valide la chaîne d'en-têtes, vérifie qu'elle porte une véritable preuve de travail, puis seulement demande les corps de blocs, ce qu'il peut faire auprès de plusieurs pairs en parallèle puisqu'il sait déjà ce qu'il cherche. Les clients légers s'arrêtent à cette première étape : un portefeuille SPV ou Neutrino conserve les en-têtes et vérifie que la branche de Merkle d'une transaction se rattache à l'un d'eux. À 80 octets chacun, une chaîne de 900 000 en-têtes représente 72 Mo, ce qui explique que cela fonctionne sur les données mobiles.
L'en-tête du bloc genesis est l'exemple canonique à examiner. Sa version est 1, son hash d'en-tête précédent est entièrement à zéro, sa racine de Merkle est 4a5e1e4b et ainsi de suite, son horodatage est 1231006505, soit le 3 janvier 2009, sa valeur nBits est 0x1d00ffff et son nonce est 2083236893. Vous pouvez hacher vous-même ces 80 octets et obtenir le hash de bloc bien connu commençant par dix zéros. Si vous voulez voir un autre en-tête, l'appel RPC getblockheader de Bitcoin Core renvoie exactement ces champs et rien d'autre.