L’en-tête de bloc

Curiosité

1. Comment une structure de seulement 80 octets peut-elle s’engager cryptographiquement sur des millions de dollars de données de transactions ?
2. Quelles règles précises empêchent un mineur de manipuler le champ timestamp pour obtenir un avantage ?
3. Pourquoi un smartphone peut-il vérifier la sécurité du réseau Bitcoin sans télécharger l’ensemble de son historique ?

Explorer

1. Chaque bloc Bitcoin commence par un en-tête de 80 octets, suivi d’une liste de transactions de longueur variable. Alors que la liste des transactions peut atteindre environ quatre millions d’octets par bloc, seul l’en-tête sert au hachage de la preuve de travail et à l’identification de la chaîne. Cet écart de taille extrême fait de l’en-tête une empreinte compacte de l’ensemble du conteneur, ce qui permet aux nœuds de traiter les métadonnées avant de télécharger le gros des données.
2. Le premier champ est « version », qui occupe quatre octets. Conçu à l’origine pour suivre les versions successives du logiciel, il contient désormais des bits de signalisation pour les soft forks selon le BIP9. Les mineurs définissent des numéros de version spécifiques pour signaler leur soutien à de nouvelles règles de consensus avant leur activation. Ce champ comporte aussi des contraintes : par exemple, le BIP34 exigeait que les blocs de version 2 intègrent la hauteur du bloc dans le script de la transaction coinbase, ce qui montre comment l’en-tête impose des changements structurels à l’ensemble du réseau.
3. Le « hash du bloc précédent » (32 octets) relie chaque bloc à son parent en contenant le double hash SHA-256 de l’en-tête précédent. Modifier ne serait-ce qu’un seul octet d’un bloc passé change son hash, ce qui rompt le lien avec tous les blocs suivants. Cette chaîne de hashes garantit que les données historiques ne peuvent pas être modifiées sans refaire le travail de calcul de tous les blocs qui suivent.
4. La « racine de Merkle » (32 octets) sert d’empreinte cryptographique pour toutes les transactions du bloc. Elle s’obtient en hachant récursivement des paires d’identifiants de transaction jusqu’à ce qu’il ne reste qu’une seule valeur. Cette structure permet la vérification simplifiée des paiements : un client léger peut prouver l’inclusion d’une transaction donnée à l’aide de cette seule racine et d’un petit ensemble de hashes frères, sans télécharger le bloc complet.
5. Le « timestamp » (4 octets) enregistre l’heure de création en secondes depuis l’époque Unix. Les règles de consensus encadrent ce champ pour empêcher toute manipulation : il doit être supérieur à la médiane des horodatages des 11 blocs précédents, et un nœud le rejette s’il est en avance de plus de deux heures sur sa propre horloge (depuis Bitcoin Core 27, l’heure système du nœud ; les versions antérieures utilisaient une heure ajustée par les pairs). Ces contraintes garantissent que les temps de bloc restent raisonnablement précis pour le calcul de la difficulté, tout en tolérant une certaine variation due aux délais de propagation sur le réseau.
6. Les champs restants sont « nBits » (4 octets), un encodage compact de la cible de preuve de travail, et « nonce » (4 octets), un nombre arbitraire que les mineurs font varier pour trouver un hash valide. Comme les en-têtes sont petits, stocker tous les en-têtes depuis 2009 demande moins de 100 Mo. Un client léger peut conserver tout cet historique, vérifier lui-même toutes les contraintes de preuve de travail et supposer, sans vérifier les transactions, que la chaîne qui cumule le plus de travail est valide.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• Bitcoin Developer Reference: Block Headers
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 11
• BIP9: Version bits-based consensus signalling (GitHub)